Berner Setterwall5 min read

    Your Coding Agent Can Now Check Its Own Cogny Sites Deploys

    You add a Stripe key to your site in Cogny, ask your coding agent to finish the checkout, and the live site still says "Payments aren't configured." The agent reads the code, the code is fine, and it has no way to see the one thing that matters: does the running site actually have the key?

    Until now, it couldn't. The agent could see the repository, but not the hosting. So it guessed. It suggested adding the variable "in your Vercel dashboard", or asked you to paste the key into the chat.

    Now it can look. Cogny Sites has four tools your agent calls from the Cogny CLI or Cogny's MCP server, and a one-page briefing that tells it how hosting works here.


    TL;DR

    • list_sites: the sites in your workspace, the address each is served at, and what's live (commit and time), plus whether a newer build is running or failed.
    • get_site: every environment variable and secret by name, whether the running site has it, and a note when something needs attention. Plus recent production and preview deployments with their build errors.
    • get_site_logs: what the live site printed, its HTTP requests, or a deployment's full build log.
    • set_site_resources: raise a site's memory (512 MiB to 4 GiB) or CPU (1 or 2) when the logs show it running out. Applies right away, no rebuild.
    • Values never come out. Not to the agent, not to the chat. Secrets stay secret.
    • Briefing for your agent: cogny.com/sites.md. Paste the link and it knows how builds, deploys and variables work on Cogny Sites.

    "Is the key set?" is now one call

    npx @cogny/cli tools call get_site --input '{"site":"owner/repo"}'
    

    The answer compares what's saved in Cogny with what the running site has, name by name:

    Environment (names only; values are never shown):
    - NEXT_PUBLIC_STRIPE_PUBLISHABLE_KEY: variable, not on the running site. Saved in
      Cogny but not on the running site yet: it takes effect on the next deploy.
    - STRIPE_SECRET_KEY: variable, on the running site. Looks like a credential but is
      stored as a plain variable; an owner can make it a secret (the lock on the
      variable in Settings).
    - STRIPE_WEBHOOK_SECRET: variable, not on the running site. Saved in Cogny but not
      on the running site yet: it takes effect on the next deploy.
    

    That's the whole diagnosis. Two keys were saved after the last deploy, and saving a variable doesn't redeploy. The fix is to press Deploy, not to hunt for a new key. It also points out that the secret key is stored as a plain variable, where it should be a secret.

    get_site writes a note for each case that usually trips people up:

    • Saved but not deployed yet: the next deploy brings it in.
    • Left over on the running site: removed in Cogny, still live until the next deploy.
    • A newer secret version isn't live yet: you rotated a secret; the site still runs the old one.
    • Build-time variables (NEXT_PUBLIC_, VITE_, PUBLIC_ and the like): they're compiled into the JavaScript, so the live site has them only if they were set when it was built.
    • A credential stored as a plain variable, and empty values.

    Why the agent never sees a value

    The tools show names, whether a value is set, and whether the running site has it. They never return the value of a variable or a secret. If a failed build's error message happens to contain a saved value, it's replaced with [redacted] before the agent sees it. Logs get the same treatment for credentials and email addresses.

    Changing variables, adding secrets and starting deploys stay with an owner or admin in Cogny. Your agent can tell you exactly what's missing, but your keys don't pass through a chat to get there.

    Logs, and the 512 MiB problem

    When the live site returns a 500, the agent reads the error instead of guessing:

    npx @cogny/cli tools call get_site_logs --input '{"site":"owner/repo","source":"requests","level":"error"}'
    npx @cogny/cli tools call get_site_logs --input '{"site":"owner/repo","level":"error","query":"/api/checkout"}'
    

    The first shows which paths fail. The second shows the stack trace behind one of them. Add "pr": 42 to read a pull request's preview instead of production, or "source": "build" for a deployment's full build log. It looks back up to 30 days and returns 50 lines by default, up to 200.

    If the logs say Memory limit of 512 MiB exceeded, the agent can raise it:

    npx @cogny/cli tools call set_site_resources --input '{"site":"owner/repo","memory":"1Gi"}'
    

    The live site gets the new size right away, without a rebuild or downtime, and every later deploy keeps it. A bigger size costs more to run, so the agent is told to check with you first. You can do the same in Cogny under Sites → the site → Resources.

    get_site_logs and set_site_resources are for workspace owners and admins, or a workspace API key.

    Brief your agent in one line

    Most hosting mistakes agents make here come from assuming Vercel. So we wrote the briefing an agent needs, in the form an agent reads best: cogny.com/sites.md. Tell it:

    Read https://cogny.com/sites.md before you change anything about hosting, deploys or environment variables.

    It covers how a build runs, what the app has to do to run here (listen on PORT, no writes to local disk), variables versus secrets, why a saved variable needs a deploy, domains and webhooks, and how to call the four tools above.

    Getting started

    1. In the workspace that hosts the site, an owner or admin copies an API key from Settings → Data & Integrations → Connect AI Clients.
    2. The agent signs in: npx @cogny/cli login --api-key <key>. Don't let it run cogny init for this; that creates a new, empty workspace that can't see your site.
    3. npx @cogny/cli tools call list_sites, then get_site.

    The same tools are on Cogny's MCP server at https://app.cogny.com/mcp if your agent connects that way, and the voice agent in the app can answer the same questions. If your site isn't on Cogny Sites yet, moving it from Vercel takes a few minutes.