Skip to content
Skip to content
PGB Learn

Deploy a container from code, GitHub or an image

Run a backend service, web app or worker in your project, with a public address and your database already connected.

Updated Nov 12, 2026

A container runs your own application: an API, a full-stack web app or a worker. Your code can be an archive you upload, a GitHub repository, any Git repository, or a ready-made image. Each container gets its own web address and has your project's database connection injected for you.

Open Containers

In your project's sidebar, under Core Services & Infrastructure, choose Containers. With nothing deployed you see Deploy First Container and a set of Quick Starter Presets: Python FastAPI / Uvicorn (port 8000), Node.js / Express API, TypeScript Service and Go Fiber Microservice (port 8080). Each has Deploy Sample for a one-click start and Customize to edit first.

Deploy step by step

Choose + Create Container. The wizard has three steps.

1. Attributes

  • Service Name: this becomes your address, name.ct.pgbhub.app. It must be a valid web-address label and unique across the platform.
  • Internal Port: the port your app listens on, for example 8000, 8080 or 3000.
  • Health Check Endpoint: a path your app answers when it is healthy, such as /health. It is used to know when the app is ready after a wake-up.
  • Compute Tier: shown with its memory and CPU. See "Size and tier" below.
  • Environment Variables: add your own. Some are injected automatically, including DATABASE_URL, STORAGE_BUCKET and PGB_PROJECT_ID.

2. Source Code: choose where the code comes from:

  • Starters or Templates: a ready-made service with the database driver included.
  • Upload: a .zip, .tar.gz or .tar archive of your project.
  • GitHub: connects the PGB GitHub app so every push to your branch redeploys the container automatically. Pick the Account, Repository and Branch.
  • Git URL: clones a public repository once for this deploy.
  • OCI Image: a ready-made image tag such as node:20-alpine.

For uploads, GitHub and Git, you can pick a Framework Preset to pre-fill the Build Command and Start Command, or set them yourself. If your repository has a Dockerfile, it is used. Otherwise one is generated for you. You can steer the generated one by committing a pgb.config.json, for example {"start_command": "node server.js"}.

3. Review & Launch: check the summary and choose Deploy Container Now.

Watch the deploy

Choose Deploy Logs on the container to follow the build. When it finishes the container shows as RUNNING. Choose Test or open its address to try it.

Size and tier

You do not choose a size by hand. After each successful build, your image's size decides the tier: Micro, Standard, Plus, Pro or Enterprise, which sets the CPU and memory the container may use and the hourly rate while it is awake. A leaner image costs less. If you need more CPU or memory than your image size gives, set a Minimum tier in the container's Compute & Storage settings. See Pricing for current rates, and Billing and the wallet.

Other actions

On a container's page: Wake, Redeploy, Duplicate (copy it into a staging or development environment, with its own variables), Docs History, Runtime Logs, Link GitHub Repo and Delete Container.

Good to know

  • Archive uploads have a size limit. If yours is too big, you are told so.
  • Requests to your container may carry bodies up to 50 MB by default.
  • Your container can only be reached over HTTPS at its address.
  • If the platform has no free container capacity, the Console shows an "At Capacity" page where you can leave your email and be told when a slot opens.
  • If your account is paused, creating containers is refused with a clear message.
  • A payment method may be required for some tiers.

More guides in Console: containers & domains