Databases on Candor Deploy

Every Candor Deploy plan includes managed databases. You pick an engine, we run it alongside your apps in the same isolated environment, and your app reaches it over a private connection string. A database on Deploy is never exposed to the internet — the only things that can talk to it are your own services.

The engines

Engine	Port	Attached to your app as
PostgreSQL	5432	DATABASE_URL
MySQL 8.4	3306	DATABASE_URL
Redis 7.4	6379	REDIS_URL

Every database gets 512 MB of memory (drawn from your plan’s pool) and a 5 GB disk volume.

How many you can run

	Solo	Studio	Org
Databases	1	3	10
Memory pool (shared with your apps)	1 GB	4 GB	10 GB

Databases have their own count — they don’t use up your apps-and-workers allowance — but each one takes its 512 MB from the same memory pool your apps share. On Solo, one database leaves 512 MB of the 1 GB pool for everything else. That’s the trade-off, so it’s written down here rather than discovered later.

Create a database

1. Log in at my.candorhost.com and open the Deployments tab.
2. On your project’s card, click + Database.
3. Give it a name and pick an engine — Postgres, MySQL, or Redis.
4. Click Create database.

The name is yours to choose (up to 63 characters, unique across your account), and it becomes the database’s private hostname: a MySQL or Redis named cache is reachable at svc-cache from your apps; a Postgres named main at svc-main-rw. Short and lowercase works best.

One Postgres quirk worth knowing: its credentials are generated a few moments after creation. If the Connect tab says the database is still starting, give it a moment and reopen the tab.

Connect your app to it

The fast way is to attach it — one click, no copying:

1. Open your app and go to its Environment tab.
2. Under Attach a database, pick the database and click Attach.
3. Redeploy the app.

Attaching writes the database’s connection URI into your app’s environment as DATABASE_URL (REDIS_URL for Redis). Like any environment change, it reaches the running app on its next deploy — the portal reminds you.

If you’d rather wire it up yourself, open the database and use its Connect tab: it shows the full connection URI plus the individual parts (host, port, database, user, password) for frameworks that take fields instead of a URI — the URI and password each have a copy button.

Per-engine notes, honestly stated:

• Postgres — anything built on psycopg 3 (SQLAlchemy, for one) wants the scheme postgresql+psycopg:// instead of the postgresql:// the URI ships with. Edit the variable if your framework complains about the driver.
• MySQL — the user and database are both named app, with a password we generate at creation. It’s all on the Connect tab.
• Redis — no password at all. That’s deliberate, and safe, because of the next section.

Private by design

Your databases have no public hostname and no open port on the internet. They’re reachable only from your own services on Candor Deploy — which is why Redis can run without a password, and why you can’t point a database client on your laptop straight at one. Talk to your data through your app, or ask us for help moving data in bulk (below).

Schema migrations and moving data in

Schema migrations are your app’s job: run them when your app starts — from your Dockerfile’s entrypoint or your repo’s own start command — the same way you would anywhere else. There’s no separate release-phase hook.

Moving an existing database in — from another host, or from a dump — is something we do for you, free, on every plan. Because databases aren’t reachable from outside, a bulk import is genuinely easier to hand to us than to script around. Open a ticket; we reply within one business day to schedule it, and once a migration is underway it gets priority attention.

Backups

Backups are included with every Deploy plan — see the plans. What the portal does not yet have is self-service backup browsing or restore, and we won’t pretend otherwise. If you need a restore, open a ticket — Candid Support response times apply. And for data you truly can’t lose, keep your own periodic dumps (pg_dump, mysqldump) as well; that’s good advice on any host, including ours.

Deleting a database

Open the database, go to Settings, and click Delete this database. Treat it as permanent — the service and its resources are removed, and deleting a whole project deletes every database in it too.

If your account is suspended for non-payment, databases are paused but their disks are kept — settle the invoice in billing and they come back.

---

Looking for MySQL on shared hosting instead? That’s a different product with its own guide: Databases on shared hosting. For the bigger picture of how Deploy runs your services, see How Candor Deploy works.