Deploy with /deploy-to-render — Pair-program with Render: deploy, debug, and monitor with the Render plugin

The plugin ships a /deploy-to-render slash command. It’s not magic - it’s a thin wrapper that invokes render-blueprints and render-deploy in sequence - but it gives you a single, repeatable entry point.

1. Push the project to GitHub

Render Blueprints deploy from a Git repo, so we need one. Create an empty repo on GitHub (call it tinylink), then:

Terminal

$git add . && git commit -m 'init: tinylink scaffold'
[main (root-commit) 9a1b2c3] init: tinylink scaffold
$git branch -M main
$git remote add origin git@github.com:you/tinylink.git
$git push -u origin main

2. Run the slash command

In your editor, with the tinylink/ folder open, run:

/deploy-to-render

The agent will respond with a deploy plan before doing anything destructive. A typical exchange:

Loading skills: render-blueprints, render-deploy, render-env-vars,
                render-cron-jobs, render-postgres, render-keyvalue.

Plan for tinylink:
  1. Author render.yaml with:
       - web service `tinylink-web`  (Python, port from $PORT)
       - Postgres database `tinylink-db`
       - Key Value instance `tinylink-kv`
       - cron job `tinylink-prune` (daily at 03:00 UTC)
     DATABASE_URL/REDIS_URL injected via fromDatabase/fromService.

  2. Validate render.yaml against the schema (the post-edit hook
     will also run automatically).

  3. Push the Blueprint with the Render API (via MCP tools:
     create_postgres, create_key_value, create_web_service,
     create_cron_job).

  4. Stream the first deploy and confirm /healthz returns 200.

Proceed?

Approve the plan. The agent writes the file:

databases:
  - name: tinylink-db
    plan: free
    databaseName: tinylink
    user: tinylink

services:
  - type: web
    name: tinylink-web
    runtime: python
    plan: starter
    buildCommand: pip install -r requirements.txt
    startCommand: uvicorn main:app --host 0.0.0.0 --port $PORT
    healthCheckPath: /healthz
    autoDeploy: true
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: tinylink-db
          property: connectionString
      - key: REDIS_URL
        fromService:
          name: tinylink-kv
          type: keyvalue
          property: connectionString

  - type: keyvalue
    name: tinylink-kv
    plan: free
    ipAllowList: []
    maxmemoryPolicy: allkeys-lru

  - type: cron
    name: tinylink-prune
    runtime: python
    plan: starter
    schedule: "0 3 * * *"
    buildCommand: pip install -r requirements.txt
    startCommand: |
      python -c "from sqlalchemy import create_engine, text; import os;
      e = create_engine(os.environ['DATABASE_URL']);
      e.begin().execute(text(\"DELETE FROM links WHERE expires_at < now()\"))"
    envVars:
      - key: DATABASE_URL
        fromDatabase:
          name: tinylink-db
          property: connectionString

A few details worth pausing on - each one is a place where a Render-aware agent does something a generic one wouldn’t:

Line(s)	What’s going on
`--host 0.0.0.0 --port $PORT`	Render injects `$PORT` at runtime; binding to `0.0.0.0` is mandatory. The plugin’s `render-platform.mdc` rule reminds the agent every time.
`healthCheckPath: /healthz`	Pairs with the endpoint we wrote in `main.py`. Without it, deploys can succeed even if the app is broken.
`fromDatabase` / `fromService`	The Blueprint pattern for wiring credentials - no copy-pasting connection strings.
`ipAllowList: []` on Key Value	Locks the KV instance to internal traffic only (no external access).
`maxmemoryPolicy: allkeys-lru`	Sensible default for a cache; rate-limit keys can be evicted under pressure.

3. Hook validation fires on save

The plugin installs an editor hook that runs the Render Blueprint validator every time render.yaml is saved. If you tweak the file by hand and break it, you’ll see something like:

\u2716 render.yaml: services[0].envVars[0].fromDatabase.property must be one
of [connectionString, host, port, database, user, password]

That’s the hook - not the deploy - catching the typo before you commit. The skill doing the work behind the scenes is render-blueprints.

4. Push the Blueprint

The agent commits and pushes the file:

Terminal

$git add render.yaml
$git commit -m 'feat: add Render Blueprint'
$git push

Then it uses MCP to register the Blueprint with Render. Under the hood that’s a sequence of tool calls:

Calling render -> list_workspaces() ... using "your-workspace"
Calling render -> create_postgres(name="tinylink-db", plan="free") ... created (postgres-srv-abc123)
Calling render -> create_key_value(name="tinylink-kv", plan="free") ... created (kv-srv-def456)
Calling render -> create_web_service(repo="github.com/you/tinylink", branch="main", ...) ... created (web-srv-ghi789)
Calling render -> create_cron_job(name="tinylink-prune", schedule="0 3 * * *", ...) ... created (cron-srv-jkl012)
Calling render -> get_deploy(serviceId="web-srv-ghi789") ... status=build_in_progress

If you’d rather drive this via the Render Dashboard instead, the workflow is New -> Blueprint -> Connect repo -> Apply - but the whole point of the plugin is that the agent does it for you.

5. Stream the first deploy

The agent will tail logs while the build runs. You can also do it yourself in another terminal:

render logs --resources tinylink-web --tail

After ~3 minutes you’ll see the build finish, the start command run, and the healthcheck go green:

==> Running build command 'pip install -r requirements.txt'...
==> Running 'uvicorn main:app --host 0.0.0.0 --port $PORT'...
INFO:     Uvicorn running on http://0.0.0.0:10000 (Press CTRL+C to quit)
INFO:     Application startup complete.
==> Your service is live at https://tinylink-web.onrender.com

Hit the public URL:

Terminal

$curl https://tinylink-web.onrender.com/healthz
{"status":"ok"}
$curl -X POST https://tinylink-web.onrender.com/links -H 'Content-Type: application/json' -d '{"url":"https://render.com"}'
{"slug":"k7Pq3m"}
$curl -I https://tinylink-web.onrender.com/k7Pq3m
HTTP/2 307
location: https://render.com

That 307 redirect is tinylink doing its actual job. You’ll deliberately break it next.

What does `fromDatabase: { name: tinylink-db, property: connectionString }` do in the Blueprint?

Creates a new Postgres database every time the web service deploysTells Render to inject the named database's connection string into the env var at runtimeCopies the connection string into the repo at build time so it can be committedConfigures the database to accept connections from the web service's IP

What you learned

Pushed tinylink to GitHub and ran the plugin's `/deploy-to-render` slash command
Watched the agent author a Blueprint with web + Postgres + Key Value + cron, wired together with `fromDatabase` and `fromService`
Saw the editor hook validate `render.yaml` on save, catching mistakes before they ship
Pushed the Blueprint to Render via MCP and confirmed the live service responds