Deploy serverless with Postgres

At the end of this guide, the service in your repository runs on Frazer Serverless at an HTTPS URL, with a managed Postgres database bound to it. Frazer builds the image, runs it in a sandbox and scales it with requests, down to zero when it is idle. The service reads DATABASE_URL; nobody copies a password.

You need:

• A project. This guide uses acme-staging.
• A repository with a stateless HTTP or gRPC service. With a Dockerfile, Frazer builds that; without one, it builds Node, Python, Go, PHP, Java, Ruby and static sites from the source.
• Code that reads its database connection string from DATABASE_URL.
• Capacity for the project: a server pool of yours or one shared with the project, or the Frazer fleet.
• The Developer role (roles/developer) in the project.

Deploy the service

1. Install the CLI and sign in.

   curl -fsSL https://get.frazer.ai | sh
   frazer login

2. Plan the deploy. From the root of the repository, ask for the service and a Postgres database:

   frazer serverless deploy notes-api --project acme-staging --source . --with postgres --dry-run

   Output

   stack notes · service notes-api · scale 0–20 · sandbox
   Postgres notes-db · binding DATABASE_URL
   https://notes-api-p7k2.frazer.run · TLS

   --with postgres adds a managed Postgres instance and a binding to it. The service, the database and the binding form a stack: they are created by one plan and deleted together. In a staging project the service starts from zero instances and scales to 20, with 80 concurrent requests per instance on a run-1x size (1 vCPU, 1 GiB).

3. Deploy. Run the same command without --dry-run:

   frazer serverless deploy notes-api --project acme-staging --source . --with postgres

   Frazer builds the image in a rootless sandbox, signs it, attaches an SBOM and pushes it to Frazer Registry. It creates the database and the first revision, notes-api-00001. Traffic moves to a revision only once it is ready, so a failed build or start never takes requests.

   Output

   notes-api is live at https://notes-api-p7k2.frazer.run · Postgres notes-db ready

4. Open it and follow the logs.

   frazer serverless services open notes-api --project acme-staging
   frazer serverless services logs notes-api --project acme-staging --follow

   When the service has scaled to zero, the first request waits while an instance starts; it is held, not answered with a 502. Each service page shows its cold-start count and wait times.

5. Look at the data. Open a session to the database over Frazer Link, with a short-lived login for your own identity:

   frazer databases connect notes-db --project acme-staging

   The database has no public address. The service reaches it through a private endpoint in the project’s VPC.

How the binding works

The binding creates a database role for notes-api, keeps its password in Frazer Secrets and injects these variables into every revision:

Variable	Value
DATABASE_URL	The connection string through the pooler
DATABASE_DIRECT_URL	The connection string without the pooler
PG*	The standard Postgres client variables

People see the names, sources and versions of variables on the service’s Variables and secrets tab, never the values. A new password rolls out as a new revision.

Ship changes

• Deploy again with frazer serverless deploy notes-api --project acme-staging --source .. Every change to the image, variables, bindings or scaling creates a new, immutable revision.

• Roll back by sending all traffic to an earlier revision:

  frazer serverless traffic notes-api --project acme-staging --to notes-api-00001=100

• Run migrations first. A release command (release in the stack file, such as alembic upgrade head) runs as a one-off job with the new revision’s image and bindings before traffic moves. If it fails, the deploy stops.

• Choose who can call it. A service is Public, behind Frazer sign-in (callers need the permission serverless.services.invoke), or Internal, with no public route and a private endpoint in the project’s VPC. Production projects warn on Public.

• Keep the stack as code. Export blueprint on the stack’s page writes it as frazer.stack.yaml, and frazer apply -f frazer.stack.yaml --dry-run plans a stack from the file.

Tip

frazer deploy, with no flags, asks once whether an app should run on Kubernetes or Serverless, recommends one from what it finds in the repository and the project, and remembers the answer in .frazer/app.yaml.

Next steps

ServerlessRevisions, traffic, scaling, access modes, domains and jobs.

DatabasesBackups and point-in-time recovery, replicas, upgrades and query insights.

SecretsWhere binding passwords live and how they rotate.

Serverless on frazer.aiThe product page, with the stack and the plan.