Database
Provision official Railway Postgres, Redis, MySQL, or MongoDB and wire connection variables into an app service without duplicating databases.
Overview
Database is an agent skill for the Build phase that provisions official Railway Postgres, Redis, MySQL, or MongoDB services and guides connecting them to your app after checking for an existing database.
Install
npx skills add https://github.com/railwayapp/railway-skills --skill databaseWhat is this skill?
- Supports four official Railway database templates: Postgres, Redis, MySQL, and MongoDB
- Mandatory check-existing-databases-first flow via environment config before any create
- Creates services through Railway CLI or API and waits for deployment to finish
- Optional handoff to wire connection variables into app services through the env skill
- Redirects non-database Railway templates (Ghost, Strapi, n8n, etc.) to the templates skill
- Four official database types: Postgres, Redis, MySQL, and MongoDB
- Check-existing-databases-first decision flow before create
- Non-database templates delegated to the templates skill
Adoption & trust: 890 installs on skills.sh; 274 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
You need persistent storage on Railway but risk spinning up duplicate databases or leaving your app without the right connection variables.
Who is it for?
Solo builders shipping a backend or full-stack app on Railway who want maintained database templates with volumes, networking, and env vars handled the platform way.
Skip if: Adding Ghost, Strapi, n8n, or other non-database Railway templates—use the templates skill instead—or teams not deploying on Railway.
When should I use this skill?
User wants to add a database (Postgres, Redis, MySQL, MongoDB), says add postgres, add redis, add database, connect to database, or wire up the database—or add postgres and connect to my server.
What do I get? / Deliverables
Your project has at most one purpose-fit Railway database service, deployment is confirmed, and—when you ask—connection variables are wired into the target service via the env skill.
- Official Railway database service (Postgres, Redis, MySQL, or MongoDB) when none existed
- Confirmation of existing database when check-first finds one
- Optional env-variable wiring handoff to the env skill
Recommended Skills
Journey fit
Adding and connecting a managed database is a core backend setup step when you are building or extending a Railway-hosted product, before you ship features that depend on persistent storage. The skill targets datastore provisioning and service-to-database wiring on Railway, which sits squarely in backend infrastructure rather than frontend or pure launch work.
How it compares
Use this for official Railway datastore provisioning with a check-first workflow, not as a generic ORM or local Docker compose setup guide.
Common Questions / FAQ
Who is database for?
It is for solo and indie developers using Railway who want an agent to add Postgres, Redis, MySQL, or MongoDB and optionally connect those services to an existing app.
When should I use database?
Use it during Build when you are standing up backend storage on Railway—phrases like add postgres, add redis, add database, connect to database, or wire up the database—or when you need to confirm an existing DB before creating another.
Is database safe to install?
It is a procedural skill that expects Bash(railway:*) access to your Railway project; review the Security Audits panel on this page and treat database creation and env wiring as production-affecting actions.
Workflow Chain
Then invoke: templates
SKILL.md
READMESKILL.md - Database
# Database Add official Railway database services. These are maintained templates with pre-configured volumes, networking, and connection variables. For non-database templates, see the `templates` skill. ## When to Use - User asks to "add a database", "add Postgres", "add Redis", etc. - User needs a database for their application - User asks about connecting to a database - User says "add postgres and connect to my server" - User says "wire up the database" ## Decision Flow **ALWAYS check for existing databases FIRST before creating.** ``` User mentions database │ Check existing DBs first (query env config for source.image) │ ┌────┴────┐ Exists Doesn't exist │ │ │ Create database │ (CLI or API) │ │ │ Wait for deployment │ │ └─────┬─────┘ │ User wants to connect service? │ ┌─────┴─────┐ Yes No │ │ Wire vars Done + via env suggest wiring skill ``` ## Check for Existing Databases Before creating a database, check if one already exists. For full environment config structure, see [environment-config.md](references/environment-config.md). ```bash railway status --json ``` Then query environment config and check `source.image` for each service: ```graphql query environmentConfig($environmentId: String!) { environment(id: $environmentId) { config(decryptVariables: false) } } ``` The `config.services` object contains each service's configuration. Check `source.image` for: - `ghcr.io/railway/postgres*` or `postgres:*` → Postgres - `ghcr.io/railway/redis*` or `redis:*` → Redis - `ghcr.io/railway/mysql*` or `mysql:*` → MySQL - `ghcr.io/railway/mongo*` or `mongo:*` → MongoDB ## Available Databases | Database | Template Code | |----------|---------------| | PostgreSQL | `postgres` | | Redis | `redis` | | MySQL | `mysql` | | MongoDB | `mongodb` | ## Prerequisites Get project context: ```bash railway status --json ``` Extract: - `id` - project ID - `environments.edges[0].node.id` - environment ID Get workspace ID (not in status output): ```bash bash <<'SCRIPT' scripts/railway-api.sh \ 'query getWorkspace($projectId: String!) { project(id: $projectId) { workspaceId } }' \ '{"projectId": "PROJECT_ID"}' SCRIPT ``` ## Adding a Database ### Step 1: Fetch Template ```bash bash <<'SCRIPT' scripts/railway-api.sh \ 'query template($code: String!) { template(code: $code) { id name serializedConfig } }' \ '{"code": "postgres"}' SCRIPT ``` This returns the template's `id` and `serializedConfig` needed for deployment. ### Step 2: Deploy Template ```bash bash <<'SCRIPT' scripts/railway-api.sh \ 'mutation deployTemplate($input: TemplateDeployV2Input!) { templateDeployV2(input: $input) { projectId workflowId } }' \ '{ "input": { "templateId": "TEMPLATE_ID", "serializedConfig": SERIALIZED_CONFIG, "projectId": "PROJECT_ID", "environmentId": "ENVIRONMENT_ID", "workspaceId": "WORKSPACE_ID" } }' SCRIPT ``` **Important:** `serializedConfig` is the exact object from the template query, not a string. ## Connecting to the Database After deployment, other services connect using reference variables. For complete variable reference syntax and wiring patterns, see [variables.md](references/variables.md). ### Backend Services (Server-side) Use the private/internal URL for server-to-server communication: | Database | Variable Reference | |----------|-------------------| | PostgreSQL | `${{Postgres.DATABASE_URL}}` | | Redis | `${{Re