Deploy a container on your own domain

When you need a container

Functions are great for small pieces of logic. When you have a whole application, such as an API with its own framework, a web app or a worker, deploy it as a container. It gets its own address, your database connection is injected, and it can sleep when idle.

Deploy a starter

1. Open Containers in the sidebar.
2. Choose + Create Container.
3. 1. Attributes: Service Name notes-api (your address becomes notes-api.ct.pgbhub.app, and names are unique across the platform), Internal Port 8080, Health Check Endpoint /health. Leave the tier at Micro. Your database link is injected automatically as DATABASE_URL, together with STORAGE_BUCKET and PGB_PROJECT_ID.
4. 2. Source Code: choose Starters and pick Node.js Express. For your own code you would choose Upload (a .zip, .tar.gz or .tar), GitHub (redeploys on every push), Git URL (clones once) or OCI Image.
5. 3. Review & Launch: check the summary and choose Deploy Container Now.

Choose Deploy Logs to watch the build. When the badge shows RUNNING, choose Test or open https://notes-api.ct.pgbhub.app/health.

Your tier follows your built image size, which sets CPU, memory and the hourly rate while awake. A leaner image costs less. See Pricing.

Configure and use secrets

Choose Configure. On Environment Variables, choose + Add Variable to add your own, then Save Container Attributes and Redeploy. Secrets from Secrets & Env are injected into every container, and a container variable with the same name wins.

If something is wrong, read Runtime Logs (turn on Auto-refresh (5s)). Typical culprits are a wrong Internal Port or a missing health check path.

Let it sleep

Open Availability & Scaling. Scale to Zero pauses an idle container and costs nothing for compute while asleep. The next request wakes it, and Sleep & Wake Status shows each wake and its Wake time. Choose Always Online for something that must answer instantly. Memory is not kept across a sleep, so save what matters to your database.

Add your own domain

You will serve the API at api.yourdomain.com.

1. Choose Custom Domains in the sidebar.
2. Under Connect a Custom Domain, pick notes-api as Target Container Service.
3. Enter api.yourdomain.com as Custom Subdomain. It must be a subdomain, because a bare root domain cannot use the required record.
4. Choose + Connect Custom Domain.
5. Create the record shown at your DNS provider: type CNAME, Name api, Value the CNAME Target displayed. If your provider has a proxy option, set the record to DNS-only, or the certificate cannot be issued.
6. Choose Check DNS. Pending DNS becomes Verified SSL once the record is seen and the certificate is active. Opening https://api.yourdomain.com once triggers the certificate.

Your .ct.pgbhub.app address keeps working beside it.

Tie it together

Point your app's API address at https://api.yourdomain.com. Your container can read the same database, with the same signed-in users, as everything you built in earlier lessons. A cron job with an HTTP target can call it on a schedule, which also wakes it.

What you built

A project with sign-in, row-level security, private file storage, functions, scheduled and background work, realtime and queues, email, and a container on your own domain. Take the final assessment to check what stuck.

Recap

• Containers run whole applications, from code, GitHub, a Git URL or an image.
• Scale to Zero saves cost, and Always Online keeps one warm.
• Use Deploy Logs and Runtime Logs to fix problems.
• Custom domains need a subdomain, a DNS-only CNAME and a Check DNS.