Databases for CI/CD and AI agents on Layerbase

Two problems have bothered me for a while, and they turned out to have the same shape.

The first: getting a real database into a CI pipeline is annoying enough that most teams do not bother. They point every test run at one shared database, watch runs step on each other, and clean up by hand. The runs that crash never clean up at all, and the stranded databases pile up.

The second: ask a coding agent about a hosted database and it will confidently quote you a price. It is usually wrong, because it is answering from training data that is months stale, from a market where everyone meters and reprices twice a year.

Both come down to state that nobody is keeping honest. So we shipped two things at once. Databases that clean up after themselves, and an agent skill that reads our prices live instead of guessing. Everything below works against Layerbase Cloud with the official layerbase CLI.

A database that deletes itself

Start with an API key. Create one in your dashboard settings, save it as a repository secret named LAYERBASE_API_KEY, and the CLI talks straight to the cloud API. No browser login, no OAuth loop in the middle of a pipeline, no session token that rots and breaks your build a month later.

bash

npm i -g layerbase
export LAYERBASE_API_KEY=sk_...

# A throwaway Postgres that destroys itself after two hours.
layerbase cloud create pr-1234 --engine postgresql --ttl 2h --json

The --ttl flag is the important part. Give a database a time to live and it is destroyed when the timer runs out, capped at 72 hours. That guarantee lives on our side, not in a teardown step you hope runs. So when a job is cancelled, times out, or a runner dies mid-run, the database still goes away. A crashed pipeline cannot leave a database sitting against your quota, which is the exact failure that makes people give up on per-run databases in the first place.

In a GitHub Actions workflow the whole loop is one job:

yaml

name: test
on: pull_request

jobs:
  test:
    runs-on: ubuntu-latest
    env:
      LAYERBASE_API_KEY: ${{ secrets.LAYERBASE_API_KEY }}
    steps:
      - uses: actions/checkout@v4
      - run: npm i -g layerbase

      - id: db
        run: |
          URL=$(layerbase cloud create ci-$GITHUB_RUN_ID \
            --engine postgresql --ttl 2h --json | jq -r .connectionString)
          echo "url=$URL" >> "$GITHUB_OUTPUT"

      - run: psql "${{ steps.db.outputs.url }}" -f seed.sql
      - run: npm test
        env:
          DATABASE_URL: ${{ steps.db.outputs.url }}

      - if: always()
        run: layerbase cloud delete ci-$GITHUB_RUN_ID --yes

Create, seed, test, delete. The explicit delete reclaims the slot immediately; the TTL covers the runs that never reach it. You are not paying for databases you finished with, and you are not maintaining a cron job that sweeps up other people's messes.

Or branch a seeded parent

Transient databases start blank, which is perfect when your tests build their own fixtures. When you want production-shaped data in the test database without re-seeding every run, branch instead of create.

A branch is a copy-on-write clone of a parent you already seeded, ready in seconds with its own connection string. Fork it at the start of a run, reset it between runs, delete it when the pull request merges. On branch-ready storage it does not duplicate your data, so a branch of a 5 GB database that changes one table costs you one table. This is the same mechanism behind our Vercel and GitHub integrations, and it works across nine engines, not just Postgres.

One caveat worth stating plainly: a transient database cannot itself be branched. Branch from a persistent seeded parent, not from a throwaway. Pick create-with-TTL when you want isolation and a hard expiry; pick branch-per-PR when you want instant real data.

An agent that reads the current facts

The same API key that authenticates CI also lets a coding agent drive Layerbase directly. We packaged that into a skill:

bash

npx layerbase agent init

That writes a SKILL.md into your project (or, with --global, into your home config) and prints an AGENTS.md snippet for Codex and other agents. Once it is installed, an agent working in your repo can do four things. It audits your package.json, environment variables, and CI config for database, cache, and search providers we can consolidate. It advises, asking what you actually pay before it claims a saving. It provisions databases over the REST API or the CLI. And it can run a read-once migration from a supported provider, the same guided flow the dashboard uses, without ever touching the source.

The part I care about most is the boring part. The skill tells the agent to fetch layerbase.com/agents.md before it states any price, plan limit, engine, or migration source. That document is generated from our own source at request time. It is not a marketing page an agent memorized last spring; it is the live capability list, regenerated on every request. So when the agent tells you what a plan costs or which engines branch, it is reading today's answer, not last quarter's.

This is only possible because our pricing is worth reading live. There is one price per plan, flat, no meters. The free tier is $0. Pro is $15 a month. There is no usage dial for an agent to guess wrong about, no compute-hour estimate to fumble, no overage it forgets to warn you about. A flat price is a fact an agent can actually state, and a live document is what keeps it current.

The honest part about limits

Creating databases from an API key is metered per calendar month by plan, and I want to be upfront about why. Free-tier CI hammering shared boxes would defeat the economics that let us keep a generous free tier at all, so programmatic creates have a monthly ceiling. Creates from the dashboard are never metered. The free plan covers a handful of programmatic creates a month, paid plans cover far more, and dedicated servers are unmetered because the hardware is yours.

Go over the limit and the API returns a clear error with your usage and an upgrade hint, so a pipeline degrades gracefully instead of failing in some cryptic way. For a busy repo, branch-per-PR is the better pattern anyway. The exact per-plan numbers live in the API reference so they stay current, which is the same reason the agent reads them live rather than trusting a number in a blog post, including this one.

Try the loop

Everything here runs on the free tier, so you can wire up the whole thing before you pay anything. Create a database, mint an API key, and drop that workflow into a repo. If you want the deeper walkthrough, the CLI docs, the CI/CD page, and the agents guide each go a level further. And if you are still deciding what an agent should store where in the first place, I wrote a separate decision guide on databases for AI agents that covers exactly that.

The goal was never to add another dashboard to click through. It was to make a real database cheap enough to be disposable, and to make our facts current enough that even a machine reading them at 3am gets them right.