--- title: "Deploy serverless with Postgres" description: "From a repository to a URL with a database." url: https://frazer.ai/docs/quickstarts/serverless-postgres index: https://frazer.ai/docs/llms.txt tokens: 1490 --- > For agents: this page is indexed at https://frazer.ai/docs/llms.txt, and every page at https://frazer.ai/llms.txt. Copy commands from this file exactly. # 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.** ```sh 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: ```sh frazer serverless deploy notes-api --project acme-staging --source . --with postgres --dry-run ``` ```text title="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`: ```sh 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. ```text title="Output" notes-api is live at https://notes-api-p7k2.frazer.run · Postgres notes-db ready ``` 4. **Open it and follow the logs.** ```sh 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: ```sh 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: ```sh 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 [Serverless](https://frazer.ai/docs/serverless) Revisions, traffic, scaling, access modes, domains and jobs. [Databases](https://frazer.ai/docs/databases) Backups and point-in-time recovery, replicas, upgrades and query insights. [Secrets](https://frazer.ai/docs/secrets) Where binding passwords live and how they rotate. [Serverless on frazer.ai](https://frazer.ai/serverless) The product page, with the stack and the plan. ## Pages in Get started - [Docs home](https://frazer.ai/docs.md) - [Bring your first server](https://frazer.ai/docs/quickstarts/first-server.md) - [Create a Kubernetes cluster](https://frazer.ai/docs/quickstarts/kubernetes-cluster.md) - [Deploy serverless with Postgres](https://frazer.ai/docs/quickstarts/serverless-postgres.md) (this page) - [Deploy an open model](https://frazer.ai/docs/quickstarts/open-model.md) - [Give your team devboxes](https://frazer.ai/docs/quickstarts/devboxes.md) - [Connect your environment repo](https://frazer.ai/docs/quickstarts/environment-repo.md)