Database

A server app that expects Postgres can keep its data in one of two places. You choose on the plan step, and you see the monthly floor before anything is created in your account.

Use your own database

Supabase, Neon, Atlas, or any Postgres you already run stays where it is. ScaleBop does not create an RDS instance.

Set DATABASE_URL on the project’s Configuration step. The value is stored as a secret and injected into the Fargate task from AWS Secrets Manager. It is not written into the task definition as plain text, and it is not committed to your repository.

The task’s outbound IP changes when a task is replaced. An IP allowlist at the database provider will not stay valid. Allow the connection with TLS and the password.

Static sites never receive this secret. If the repository expects the connection string in the browser bundle, readiness stays blocked until that reference is removed.

Supabase

When your app uses Supabase, the Configuration step shows a Supabase card. Your database, users and files stay in your Supabase project. ScaleBop only passes the project’s settings to your app on AWS.

The card lists each Supabase setting your app reads, with what it is and where it may go:

Setting	Example name	Safe in the browser?
Project URL	VITE_SUPABASE_URL, NEXT_PUBLIC_SUPABASE_URL	Yes
Project ID	VITE_SUPABASE_PROJECT_ID	Yes
Anon (publishable) key	VITE_SUPABASE_ANON_KEY, VITE_SUPABASE_PUBLISHABLE_KEY	Yes. Row Level Security decides what it can read and change.
Service role (secret) key	SUPABASE_SERVICE_ROLE_KEY	No. Store it as a secret and read it only in server code.
Database connection string	DATABASE_URL	No. Store it as a secret.

• Fill in sets the project URL and project ID from the project ScaleBop found in your code. Add opens the variable editor with the right type already chosen.
• The links on the card open your project’s API keys and database settings in Supabase, where you copy each value.
• Check connection asks your Supabase project whether it is up and accepts your anon key. If the project doesn’t answer, it may be paused: free Supabase projects pause after a week without use. Restore it in the Supabase dashboard, then check again.

The service role key skips every Row Level Security rule. If it has a browser prefix such as VITE_ or NEXT_PUBLIC_, it ends up in your site’s code where anyone can read it, so readiness is blocked until you rename it and read it only on a server. ScaleBop also refuses to save a service role or secret key as a plain value. If the key was ever published, rotate it in Supabase.

Apps built with Lovable often keep the project URL and anon key in their code instead of in environment variables. That’s fine, because both are safe in the browser. The card then has nothing for you to set.

Run Supabase migrations on deploy

If your repository has a supabase/migrations folder, the deploy workflow can apply it with supabase db push before it updates your app. It is off by default. To turn it on, open Run migrations on deploy on the Supabase card:

1. Paste your project’s Session pooler connection string. In Supabase, choose Connect, then Session pooler, and copy the string with your database password filled in. ScaleBop saves it as the SUPABASE_DB_URL secret in your GitHub repository and doesn’t keep a copy. If ScaleBop created the Supabase project for you, the secret is already set.
2. Confirm that migrations change your production database.
3. Choose Turn on migrations. They run from the next production deploy.

The direct connection (db.<project>.supabase.co) doesn’t work here: GitHub’s runners can’t reach it, because it only has an IPv6 address.

What to expect:

• A failed push stops the deploy. Your app never ships against a schema it doesn’t match. Migrations before the one that failed may already be applied, because each migration runs on its own.
• Migrations aren’t undone. A redeploy doesn’t reverse them, and a rollback skips the migration step. Fix a bad migration with a new migration.
• The deploy log lists the migrations first. The step runs supabase db push --dry-run before it applies anything.
• Schema changes made in the Supabase dashboard stop the push. When the database has migrations your repository doesn’t, supabase db push refuses to run and ScaleBop reports “migrations that aren’t in your repository”. Run supabase db pull, commit the new migration file, then deploy again.

Setups generated before this option existed don’t have the migration step. The card then asks you to choose Update setup first.

Create Postgres in your AWS account

Confirming this option creates a private PostgreSQL 16 instance:

• db.t4g.small by default (or db.t4g.medium), single-AZ unless you turn on Multi-AZ
• 20 GB of encrypted gp3 storage, with a cap so the disk can grow and cannot grow without a ceiling
• 7 days of backups, unless you choose a longer retention
• deletion protection on
• no public address, and port 5432 open only to the application and to the one-off migration task
• no NAT gateway

The application connects as its own database role. The master password is not given to the app. The connection uses sslmode=verify-full. Generated images install the Amazon RDS certificate authority. A Dockerfile you wrote must install that certificate too. ScaleBop will not turn certificate checks off to make the first connection succeed.

The first workflow run creates the database. In GitHub Actions that step is named Creating the database and usually takes about ten minutes.

Deleting the project in ScaleBop does not delete the database. Deleting the CloudFormation stack fails while deletion protection is on. The destroy workflow is the path that turns protection off, removes the instance, and keeps the automated backups.

Migrations

Schema changes run as a one-off task after the image is pushed and before the service switches to that image. If the task fails, the previous service keeps running. Health checks run only after the service has rolled.

Prisma repositories run npx prisma migrate deploy. Drizzle, Knex, TypeORM, Django, and Alembic are shown as the command you confirm. ScaleBop does not guess a command from an npm script.

Migrations have to be safe for the version that is still serving traffic. Add a column before the new code reads it. App containers do not migrate when they boot.

Running migrations against a database ScaleBop does not own needs a separate confirm on the plan step.

SQLite and MongoDB

SQLite on a container is not supported. The file is gone when the task is replaced. Use Postgres instead.

MongoDB stays at the provider you already use, such as Atlas. ScaleBop does not create DocumentDB.

Snapshots

Automated backups live with the RDS instance in the AWS console. They are kept when the instance is deleted. Restoring a snapshot is something you do in the RDS console. There is no restore button in ScaleBop.