Deploy to Render

3.1 Write the Blueprint

Create render.yaml at the repo root:

databases:
  - name: sentex-postgres
    databaseName: sentex
    user: sentex
    plan: starter
    region: oregon

services:
  - type: keyvalue
    name: sentex-redis
    plan: starter
    region: oregon
    ipAllowList: [] # private — reachable only from services in this workspace

  - type: web
    name: sentex-api
    runtime: docker
    region: oregon
    plan: starter
    dockerfilePath: apps/api/Dockerfile
    dockerContext: apps/api
    domains:
      - api.sentex.gritcms.com
    preDeployCommand: sh -c "./migrate && ./seed"
    envVars:
      - key: APP_ENV
        value: production
      - key: POSTGRES_HOST
        fromDatabase: { name: sentex-postgres, property: host }
      - key: POSTGRES_PORT
        fromDatabase: { name: sentex-postgres, property: port }
      - key: POSTGRES_USER
        fromDatabase: { name: sentex-postgres, property: user }
      - key: POSTGRES_PASSWORD
        fromDatabase: { name: sentex-postgres, property: password }
      - key: POSTGRES_DB
        fromDatabase: { name: sentex-postgres, property: database }
      - key: REDIS_URL
        fromService: { type: keyvalue, name: sentex-redis, property: connectionString }
      - key: APP_URL
        value: https://api.sentex.gritcms.com
      - key: CORS_ORIGINS
        value: https://sentex.gritcms.com,https://admin.sentex.gritcms.com
      - key: R2_ACCOUNT_ID
        sync: false
      - key: R2_ACCESS_KEY_ID
        sync: false
      - key: R2_SECRET_ACCESS_KEY
        sync: false
      - key: R2_BUCKET
        sync: false
      - key: R2_ENDPOINT
        sync: false

  - type: web
    name: sentex-admin
    runtime: docker
    region: oregon
    plan: starter
    dockerfilePath: apps/admin/Dockerfile
    dockerContext: .
    domains:
      - admin.sentex.gritcms.com
    envVars:
      - key: NEXT_PUBLIC_API_URL
        value: https://api.sentex.gritcms.com
      - key: NEXT_PUBLIC_WEB_URL
        value: https://sentex.gritcms.com
      - key: NEXT_PUBLIC_ADMIN_URL
        value: https://admin.sentex.gritcms.com
      - key: THEME
        value: atlas
      - key: SOCIAL_AUTH_ENABLED
        value: "false"
      - key: NEXT_PUBLIC_DEMO_LOGINS
        value: "false"

  - type: web
    name: sentex-web
    runtime: docker
    region: oregon
    plan: starter
    dockerfilePath: apps/web/Dockerfile
    dockerContext: .
    domains:
      - sentex.gritcms.com
    envVars:
      - key: NEXT_PUBLIC_API_URL
        value: https://api.sentex.gritcms.com
      - key: NEXT_PUBLIC_ADMIN_URL
        value: https://admin.sentex.gritcms.com
      - key: THEME
        value: atlas
      - key: SOCIAL_AUTH_ENABLED
        value: "false"

Notes on the choices above, matching what’s in docker-compose.prod.yml:

• dockerContext mirrors the Compose build.context for each service: apps/api for api (matches context: ./apps/api), and . (repo root) for admin/web (matches context: ., needed for the pnpm workspace). dockerfilePath is always relative to the repo root regardless of dockerContext.
• preDeployCommand replaces the standalone migrate service the same way Railway’s Pre-Deploy Command did — it runs in a fresh instance, before the new api version goes live, and aborts the deploy on non-zero exit. Wrap it in sh -c "..." so && is interpreted by a shell, same reasoning as the Railway guide.
• type: keyvalue is Render’s current Redis-compatible managed store (runs Valkey; redis is a deprecated alias for the same type). Setting ipAllowList: [] keeps it unreachable from the public internet — only other services in your Render workspace can reach it.
• Build args: Render automatically forwards a Docker service’s envVars into the build as ARGs (as long as the Dockerfile declares matching ARG lines) — so no separate build-args block is needed for admin/web’s NEXT_PUBLIC_* values, same requirement as in the Railway guide.
• sync: false on the R2 credentials means Render will prompt you to type the actual values into the dashboard the first time the Blueprint syncs, rather than committing secrets into render.yaml.

Commit and push render.yaml.

3.2 Deploy the Blueprint

1. 1
   In the Render Dashboard, click New → Blueprint.
2. 2
   Connect your GitHub account if you haven’t, then select the sentex repository.
3. 3
   Render detects render.yaml at the repo root automatically. Give the Blueprint instance a name and pick the branch to track.
4. 4
   Render shows a preview of every resource it’s about to create (sentex-postgres, sentex-redis, sentex-api, sentex-admin, sentex-web). Review it, then fill in the prompted values for the sync: false variables (your real R2 credentials).
5. 5
   Click Deploy Blueprint.

3.3 Domains

1. 1
   Because domains: is already set per service in render.yaml, Render provisions those custom domains automatically as part of the sync — you don’t need a separate manual step to attach them.
2. 2
   Render shows you the CNAME target for each domain (under that service’s Settings → Custom Domains). Create the corresponding CNAME records at your DNS provider:

   api.sentex.gritcms.com    → CNAME → <target shown by Render>
   admin.sentex.gritcms.com  → CNAME → <target shown by Render>
   sentex.gritcms.com        → CNAME → <target shown by Render>

   Copy to clipboard
3. 3
   Wait for DNS to propagate and for Render to show each domain as verified with an active TLS certificate.

3.4 Verify and iterate

1. 1
   Check each service’s Logs tab — confirm the sentex-api pre-deploy log shows ./migrate && ./seed exiting 0 before the service starts.
2. 2
   Visit all three domains, confirm no CORS errors, and confirm the seeded demo login works.
3. 3
   Because Blueprints auto-redeploy affected services whenever render.yaml changes, and each service still auto-deploys on pushes to its watched paths, day-to-day pushes to main behave like the Railway and Dokploy/Coolify GitHub-connected flows — no manual redeploy step needed.