Postgres + Doable
Doable doesn't provision Postgres on its own infrastructure, the dedicated providers (Neon, Supabase) are very good and run on accounts you can keep independent of your deploy platform. Instead, `doable addon attach` saves a connection string to your project as an encrypted env var.
The attach command works the same way for Neon, Supabase, Upstash, MongoDB Atlas, or any Postgres / Redis / MongoDB URL.
In the Neon console, copy the pooled connection string for your branch. It looks like `postgresql://user:[email protected]/dbname`.
Run from the project directory. The string is encrypted with AES-256-GCM and stored on the project as the `DATABASE_URL` env var (configurable with `--env-key`).
doable addon attach postgres "postgresql://..."New deploys read env vars at start time. Existing containers keep their old environment until they restart.
doable deployRead `DATABASE_URL` (or the key you chose) like any other env var, Prisma, SQLAlchemy, pg, postgres.js all work.
Connection strings are encrypted at rest with AES-256-GCM using a master key that lives outside the database. Plaintext only exists in memory at container start time when the agent injects the env var. The reveal endpoint is rate-limited and audit-logged so accidental shares leave a trail.
If you rotate the credential in Neon's dashboard, run `doable env set DATABASE_URL <new-url>` and redeploy. No re-attach needed.
We get this question a lot, the short answer is that Neon and Supabase are excellent at their job, and we're focused on making the deploy half of the workflow excellent at ours. Splitting your database from your deploy platform also means you can move either independently without losing data.
On a BYO server you can opt in to native Postgres, Redis, or MongoDB containers managed by the agent, that's the path if you want everything on one host. `doable server addons enable <id>` then `doable addon create --engine postgres`.
Any provider with a standard connection string. Neon, Supabase, Upstash, MongoDB Atlas, AWS RDS, ElephantSQL, your own self-hosted instance, all work the same way. The attach command is just a convenience wrapper around storing an encrypted env var with a descriptive label.
Yes, `doable env set DATABASE_URL <new-url>` then redeploy. The new env var is read at container start. Existing containers keep their old credential until they're replaced.
No. Doable sanitises connection strings out of error messages and the agent never prints env var values. The reveal endpoint requires explicit user action and writes an audit log entry every time it's called.
Yes, run `addon attach` in each project directory. Each project gets its own encrypted copy of the env var; revoking access means clearing it from each project individually.
No credit card. Deploy your first project in under a minute.