DEV Community: Saif Ali

When your AI agent's deployment fails, it can open the support ticket too

Saif Ali — Sat, 12 Sep 2026 21:04:34 +0000

When your AI agent's deployment fails, it can open the support ticket too

Published: September 6, 2026
Category: AI · MCP · Operations
Reading time: 9 minutes
Author: NEXUS AI Team

An agent wrote the code. An agent built the container. An agent ran the deploy. Then the health check went red and the agent stopped, because that is where most agent workflows end: generation succeeds, operations fail silently, and a human finds out later.

It does not have to end there. The same NEXUS AI MCP connection that let the agent deploy also lets it read the logs, try the reversible fixes, and, when the problem is on the platform side, open a support ticket with the full context already attached.

This post is the workflow for that last step. When to escalate, what to put in the ticket, and how to keep the agent from filing noise.

Why an agent-filed ticket is a better ticket

A human filing a deployment ticket at 2 AM writes three sentences and goes back to bed. "Deploy is failing. Not sure why. Here is the URL." The support engineer then spends the first reply asking for the deployment ID, the build logs, the last thing that changed, and the exact error text.

The agent already has all of that. It is in the conversation. It knows the deployment ID because it created the deployment. It has the build logs because it just read them. It knows what changed because it made the change. An agent-filed ticket can open with the evidence that a human ticket takes two round trips to collect.

That is the real argument for handing this to the agent. Not that humans cannot file tickets, but that the agent is holding the context at the exact moment it is worth capturing.

Before the agent files anything

Most failed deploys are not support tickets. They are one of:

A build error in the generated code. The agent should read the log, fix the code, and redeploy.
A missing environment variable or secret. The agent should check what the app expects and what is set.
A bad start command or port. The agent should correct it and redeploy in place.
A transient failure. A plain redeploy fixes it.

A support ticket is for the cases that survive all of that: the build succeeds but the container never becomes healthy, a platform resource is stuck, provisioning hangs, or the behavior contradicts the documentation. Teach the agent to exhaust the cheap fixes first. The workflow below builds that in as Step 3.

Connect the NEXUS AI MCP server

If the agent already deploys to NEXUS AI, this is done. If not:

claude mcp add --transport http nexus-ai https://mcp.nexusai.run/mcp

For Claude Desktop, ChatGPT, Cursor, or any other MCP client, add the same URL as a custom connector and sign in with your NEXUS AI account. Authentication is OAuth, so the agent acts as you, sees only your organization, and every call it makes is written to the audit log against its own token. Full setup for each client is in MCP-driven deploys.

The four support tools the agent needs:

Tool	Purpose
`nexusai_support_ticket_create`	Open a ticket. Requires `subject` and `description`. Optional `priority` and `category`.
`nexusai_support_ticket_list`	List your organization's tickets, filterable by status.
`nexusai_support_ticket_get`	Read one ticket and its full message thread.
`nexusai_support_ticket_reply`	Post a reply into an existing ticket.

The failure-to-ticket workflow

Step 1 - Confirm the deployment actually failed

A red status in one place is not confirmation. The agent should check status and health together before deciding anything is wrong.

nexusai_deploy_status   deploymentId: <id>
nexusai_deploy_health   deploymentId: <id>

status tells you whether the build finished and what state the deployment is in. health returns the health check result and recent health-probe output. A deployment that is RUNNING with a failing health check is a different problem from one stuck in BUILDING, and the ticket should say which.

Step 2 - Pull the evidence

nexusai_deploy_logs   deploymentId: <id>

This returns the recent build and runtime log lines. The agent should read them, not summarize them away. The specific error string is what a support engineer searches for. The agent should also note, from its own conversation history:

The deployment ID and the deployment URL.
The framework and provider (NEXUS AI managed, AWS, Google Cloud, or Azure).
The last change it made before the failure, and whether a previous revision of this deployment was healthy.

Step 3 - Try the reversible fixes

If a previous revision was healthy and the current one is not, roll back first and confirm the app recovers:

nexusai_deploy_rollback   deploymentId: <id>

If the failure looks transient, or the fix was a corrected env var or start command, rebuild in place:

nexusai_deploy_redeploy   deploymentId: <id>

Redeploy keeps the same deployment ID, the same URL, and the same attached databases. If either of these resolves it, there is no ticket to file. The agent should report what it did and stop.

Step 4 - Open the ticket with full context

If the deployment still will not become healthy and the cause is not in the code or the configuration, this is a platform issue. Open the ticket:

nexusai_support_ticket_create
  subject:     Deployment <id> builds successfully but never passes health check
  description: |
    Deployment ID: 84a423e5089f
    URL: https://my-app.nexusai.run
    Provider: NEXUS AI managed
    Framework: Next.js

    The build completes and the container starts, but the HTTP health
    check on port 3000 has failed continuously for 20 minutes. The app
    logs show it bound to port 3000 and printed "ready on 3000".

    Last runtime log lines:
    <paste the exact lines>

    Tried: redeploy in place (same result), rollback to the previous
    revision 7c1f0a2 (that revision is healthy). The only change between
    them is an added POST /api/upload route.
  category:    deployment
  priority:    HIGH

Category should be deployment for a deploy that will not run, database for a managed database problem, billing for anything about plan limits or charges, technical for API or MCP behavior, and general for the rest. Priority should be URGENT only for a production outage with users affected, HIGH for a blocked deploy with no workaround, MEDIUM for most things, and LOW for questions.

The tool returns the ticket ID. The agent should surface it to you.

Step 5 - Track and close it

The ticket is a normal ticket. It appears in the dashboard Support screen, and the agent can follow it from chat:

nexusai_support_ticket_list   status: OPEN
nexusai_support_ticket_get    ticketId: <id>

When the team replies with a fix or a question, the agent can respond in the same thread:

nexusai_support_ticket_reply
  ticketId: <id>
  message:  Applied the suggested start command override. The health
            check passed on the next redeploy and the container is
            stable. Please close this.

There is one queue. A reply the agent posts here is visible to you in the dashboard, and a reply you post in the browser is visible to the agent.

What a good agent-filed ticket looks like

The difference is entirely in the description.

Weak:

My deployment is not working. Can someone look at it?

Strong:

Deployment 84a423e5089f (https://my-app.nexusai.run, NEXUS AI managed, Next.js). Build succeeds, container starts, HTTP health check on port 3000 has failed for 20 minutes. App logs show it bound to 3000. Rollback to revision 7c1f0a2 is healthy; the only diff is a new POST /api/upload route. Redeploy in place did not help. Runtime logs attached below.

The strong version is answerable on the first reply. The agent can produce it in one turn because it is not reconstructing anything. It is reporting what it already did.

A system prompt for knowing when to escalate

Drop this into the agent's instructions for operations work:

When a NEXUS AI deployment fails:
1. Check nexusai_deploy_status and nexusai_deploy_health.
2. Read nexusai_deploy_logs in full. Identify the exact error.
3. If the error is in the code or config, fix it and redeploy.
4. If a previous revision was healthy, roll back and confirm recovery.
5. If the build succeeds but the container never becomes healthy, or a
   platform resource is stuck, or behavior contradicts the docs: open a
   support ticket with nexusai_support_ticket_create. Include the
   deployment ID, URL, provider, framework, exact error lines, and every
   fix you already tried. Category "deployment". Priority "HIGH" unless
   users are affected, then "URGENT" and tell me first.
6. Never open a second ticket for a problem that already has an open one.
   Check nexusai_support_ticket_list first.
7. Report the ticket ID to me.

What the agent should not do

File duplicates. Before creating a ticket, the agent should call nexusai_support_ticket_list with status: OPEN and check whether this deployment already has one. A second ticket for the same failure splits the thread.

File for user errors. A wrong environment variable, a typo in the start command, code that does not compile: the agent fixes those, it does not escalate them.

Open URGENT tickets unattended. URGENT should mean a human is also being paged. The agent should confirm with you before setting it, unless you have explicitly told it that a production outage is always URGENT.

Paste secrets into the description. nexusai_secrets_list returns names and metadata, never values, and the platform never returns a decrypted secret over the API or MCP. The agent should keep it that way and never quote a secret value, a token, or a connection string into a ticket body.

Frequently asked questions

Can Claude or ChatGPT actually create a support ticket on my NEXUS AI account?

Yes. Once the NEXUS AI MCP connector is attached and signed in, the assistant can call nexusai_support_ticket_create. It acts as your account, scoped to your organization, and the ticket is identical to one opened from the dashboard.

Does an agent-filed ticket go to a different queue?

No. There is one queue. Tickets opened through MCP appear in the dashboard Support screen with the same thread, and replies posted in either place are visible in both. See the customer support page for the full picture.

Which NEXUS AI plans include support tickets?

Starter and above. Starter includes email support and support tickets. Pro adds phone support on top. Free is community support. The pricing page has the breakdown.

Should the agent try to fix the deployment before filing a ticket?

Yes, and the workflow above makes that Step 3. Read the logs, fix code or config errors, roll back if a previous revision was healthy, and redeploy. A support ticket is for what survives all of that: a build that succeeds but never runs, a stuck platform resource, or behavior that contradicts the documentation.

How does the agent follow up on a support ticket?

nexusai_support_ticket_list to see open tickets, nexusai_support_ticket_get to read a thread, and nexusai_support_ticket_reply to respond. The agent can confirm a fix worked and ask for the ticket to be closed, all from chat.

What stops an agent from spamming tickets?

Instruction and the audit log. The system prompt above tells it to check for an existing open ticket first. Every ticket action is recorded against the agent's token, so a misbehaving agent is visible and its access is revocable from the dashboard.

Can the agent see other organizations' tickets?

No. The connector signs in as you, so it reaches only your own organization, with no more access than your account has.

Where to start

Give your agent read access first and watch it triage a few failures. When you trust its judgment on what is a real platform issue, let it file. From that point, a failed deploy at 2 AM is a ticket that is already written, already has the logs, and is waiting for a reply when you wake up.

Start free and connect the MCP server, or read Your AI app is generated. Now how do you deploy it? for the wider shift this is part of.

When your AI-generated app outgrows Vercel

Saif Ali — Sat, 12 Sep 2026 21:00:42 +0000

When your AI-generated app outgrows Vercel

Published: September 6, 2026
Category: AI Deployments · Platforms
Reading time: 7 minutes
Author: NEXUS AI Team

You built the app with v0, Claude, or Cursor. You pushed it to Vercel. The preview URL worked, the production URL worked, and for a week everything was fine.

Then you added the first feature that has to remember something. A saved record, an uploaded file, a job that runs after the request finishes. And the deploy that took thirty seconds now needs a database, a place to put files, and a process that stays running. That is the moment people start searching for a Vercel alternative, and it is worth understanding what actually changed.

This post is a decision guide. What Vercel is genuinely good at, the specific signals that your app has moved past it, the options when it has, and what moving looks like.

What Vercel does well

Vercel is one of the best frontend platforms available. Git-connected deploys, a preview URL for every pull request, an edge network that is fast almost everywhere, and a developer experience that set the standard the rest of the industry now copies. For a marketing site, a docs site, a dashboard that talks to an API you host elsewhere, or a Next.js frontend with light serverless routes, it is hard to beat and there is no reason to leave.

The question is not whether Vercel is good. It is whether your app still fits the shape Vercel is built for.

The four signs your app has outgrown it

A database is now the center of the app

An AI code generator does not stop at the interface. Ask it for a working app and it gives you a users table, a posts table, auth, and a schema that the whole thing depends on. That database is not an add-on to your frontend. It is the app.

On Vercel, persistent data comes through the storage marketplace: a managed Postgres, a key-value store, and blob storage, each provisioned as a separate integration with its own billing line and its own access model. It works, and for a single database it is convenient. It also means the thing your app is built around lives outside the platform that deploys your app, wired together by you.

You need something that runs longer than a request

Serverless functions are built to handle a request and exit. They are excellent at that. They are not built to run a queue consumer, process an upload in the background, keep a websocket open, run a nightly reconciliation job that takes four minutes, or hold a warm connection pool.

If your AI-generated app has a "send the email after checkout", an "process the CSV the user uploaded", or a "poll this external API every few minutes", you are now trying to fit a long-running workload into a request-shaped runtime. That is the point where you want a container that stays up and a worker process next to it.

Files have to live somewhere

Profile pictures, exported reports, generated images, model artifacts. The moment your app accepts an upload or produces a file, you need object storage, and on a frontend platform that is another marketplace integration and another bill.

You want it running in your own cloud account

Sometimes the reason has nothing to do with the app's shape. A compliance requirement, an existing committed spend on AWS, Google Cloud, or Azure, a data residency rule, or a security review that asks where exactly the data sits. Vercel runs your app on Vercel's infrastructure. If the answer needs to be "in our own account", that is a different kind of platform.

The options once you have outgrown it

Path	What it looks like	Trade-off
Stay on Vercel, add the pieces	Keep the frontend on Vercel, add a Postgres integration, a KV store, blob storage, and a separate service for background jobs	Fastest to set up. Several billing lines, several dashboards, and background work still has no natural home.
Move to a container platform	Redeploy the app as a long-running container on Railway, Render, or Fly, add a managed database from the same provider	One runtime that fits the app. You still wire storage, backups, and multi-cloud yourself, and the AI build-and-deploy loop is gone.
Move to NEXUS AI	One deploy provisions the app container, a managed database, an optional Redis, a worker, an S3-compatible bucket, encrypted secrets, backups, and a public URL	One platform for the full stack. Frontend-only edge cases are better served by a frontend platform.

There is no single right answer. If you have one database and no background work, adding a Vercel Postgres integration is genuinely the least effort. If the app has a backend, a queue, uploads, and a schema it lives on, a platform built for that shape will cost you less over the next year in wiring and operations.

What NEXUS AI gives you in one deploy

NEXUS AI is a Vercel alternative for the case where the app is full-stack. One nexus deploy builds the container, provisions the Postgres, Redis, and workers the app asks for, attaches a bucket for uploads, injects secrets from an encrypted vault, opens a public HTTPS URL, and starts streaming build and runtime logs. After that first deploy you get versioned rollback, replica scaling, encrypted backups with signed download URLs, and cross-service restore, from the dashboard, the CLI, the REST API, or an MCP agent.

You do not have to start over to try it. Import the repository from GitHub, keep the Next.js frontend exactly as it is, and keep iterating in the AI App Builder with a live preview. The full comparison is on the Vercel alternative page.

Moving over: what to check first

Before you migrate anything, make a list of what the app actually depends on:

Environment variables. Everything in Vercel's project settings needs to move to the NEXUS AI secrets vault. Database URLs and storage credentials will be replaced with the ones NEXUS AI provisions.
The database. You can point the app at the managed Postgres NEXUS AI creates, or bring an existing Neon, Supabase, or PlanetScale database and connect it. Migrating the data is a pg_dump and restore.
File storage. Any code that reads or writes to Vercel Blob needs to point at the attached S3-compatible bucket instead. The API is S3-compatible, so an existing AWS SDK client usually needs only a new endpoint and credentials.
Background jobs. Anything currently running as a Vercel Cron or a fire-and-forget function moves to a worker process, which runs continuously next to the app.
The frontend build. Framework detection handles Next.js, Vite, Astro, and the rest. The build command and output directory carry over from what you already have.

For a worked example of taking an AI-generated frontend and giving it a real backend end to end, see From v0 prototype to production database in 5 minutes.

Frequently asked questions

Is NEXUS AI a Vercel alternative?

For full-stack apps, yes. NEXUS AI deploys a long-running backend container alongside managed databases, Redis, workers, persistent volumes, S3-compatible storage, backups, and rollback, in one workflow. For a frontend-only site with light edge functions, a dedicated frontend platform is the better fit.

Can I keep my Next.js app?

Yes. NEXUS AI detects Next.js and builds it the same way you build it locally. You keep the framework, the code, and the routing. What changes is the runtime underneath and the services attached to it.

Do I have to move my database?

No. You can use the managed Postgres NEXUS AI provisions, or connect an existing database from Neon, Supabase, PlanetScale, or your own instance. If you do move the data, it is a standard dump and restore.

What replaces Vercel's preview deployments?

The AI App Builder gives a live preview of the app as you change it, and NEXUS AI supports separate development and production environments per project so you can test a change before it reaches the production URL.

Is NEXUS AI cheaper than Vercel?

It depends on the app. A frontend with almost no backend is cheap to run on Vercel and there is little to gain by moving. A full-stack app that needs a database, a KV store, blob storage, and a background worker adds up to several billing lines on a frontend platform, and consolidating those onto one platform usually costs less. Compare against your actual usage on the pricing page.

Can my AI agent do the migration?

Yes. NEXUS AI exposes 73 MCP tools, so Claude, Cursor, or Codex can import the repository, provision the database and storage, move the environment variables, deploy, and stream the logs back to you. See MCP-driven deploys.

Where to start

If your app is still mostly a frontend, you probably do not need to move. If it has a database it is built around, background work, file uploads, or a requirement to run in your own cloud account, it has outgrown a frontend platform, and the wiring only gets heavier from here.

Start free and import your repository, or read the Vercel alternative comparison for the feature-by-feature breakdown.

Headless App Deployment with MCP: How AI Agents Push, Preview, and Ship Apps Without a Dashboard

Saif Ali — Sat, 12 Sep 2026 20:57:34 +0000

What headless app deployment actually means

Most "AI app builders" still expect a person in the loop: open a browser, click Deploy, wait for a progress bar. Headless app deployment removes that step entirely. Every action in the lifecycle, from writing the first file to rolling back a bad release, happens through a tool call an agent can make on its own, with no dashboard tab ever required to open.

NEXUS AI exposes its full app lifecycle, generation, live preview, container builds, deployment, logs, health checks, scaling, and rollback, as MCP (Model Context Protocol) tools with structured, AI-readable responses. That means a conversation with Claude, Cursor, Codex, or a custom MCP client can start with a one-line prompt and end with a running production app and a public URL, without a human touching a UI in between.

This guide covers the two tools that make headless deployment possible, nexusai_builder_push and nexusai_builder_pull, then walks through the complete headless workflow: generate, preview, deploy, operate.

The headless preview layer: nexusai_builder_push and nexusai_builder_pull

Before an app deploys, it usually needs a preview. In a normal AI app builder, that preview only exists inside a browser tab a person is looking at. Headless deployment needs the same preview, but reachable from a tool call instead of a click.

nexusai_builder_push takes a projectId and an array of files, each with a path and full content (not a diff), plus an optional note. It writes those files into that project's Builder session and returns:

{
  "sessionId": "bld_8f2a1c",
  "builderUrl": "https://nexusai.run/projects/proj_419/builder",
  "filesCount": 6,
  "snapshotMessageId": "msg_a91f"
}

The builderUrl is a live, in-browser preview a person can open at any point, but the agent never has to open it itself to keep working. Every push is a restorable checkpoint, so nothing from an earlier round is ever lost.

nexusai_builder_pull takes just a projectId and reads the latest file snapshot back, including any changes a person made by hand in the browser UI. This is what keeps an agent-authored app and a human-edited one in the same conversation instead of forking into two versions: an agent can push a first draft, a designer can nudge the layout in the browser, and the agent's next nexusai_builder_pull call sees that edit before writing another line of code.

Used together, these two tools form a loop: push files, get a preview URL, optionally pull back changes, repeat, all without a dashboard.

Step 1 — Generate the files from a prompt

An MCP-compatible agent starts the same way a person would in the AI App Builder: with a description of the app. The difference is that instead of typing into a chat window inside NEXUS AI, the agent is already inside its own conversation (Claude, Cursor, Codex, or a custom client) and generates the file set itself, in memory, based on the prompt.

There is no NEXUS AI-specific step here. This is ordinary code generation. The headless part starts at the next step.

Step 2 — Push to a live preview with nexusai_builder_push

Once the files exist, the agent calls nexusai_builder_push with the target projectId and the generated files:

{
  "tool": "nexusai_builder_push",
  "arguments": {
    "projectId": "proj_419",
    "files": [
      { "path": "app/page.tsx", "content": "export default function Page() { ... }" },
      { "path": "app/api/tasks/route.ts", "content": "export async function GET() { ... }" }
    ],
    "note": "Initial generation: task list with a Postgres-backed API route"
  }
}

The response includes the builderUrl. The agent can hand that URL straight back to the person it's working for, "here's a live preview," without NEXUS AI, the agent, or the person needing to spin up any infrastructure. Nothing is deployed yet; this is a sandboxed, in-browser preview only.

Step 3 — Pull back any edits with nexusai_builder_pull

If a person opens the builderUrl and tweaks something by hand, the agent's next move before writing more code should be:

{
  "tool": "nexusai_builder_pull",
  "arguments": { "projectId": "proj_419" }
}

This returns the current file snapshot, browser edits included. The agent now has the real, current state of the project before it generates the next round of changes or decides the app is ready to ship. Skipping this step is the single most common way an agent silently overwrites a person's manual fix.

Step 4 — Deploy and operate without opening a dashboard

Once the preview looks right, the same MCP session moves straight into deployment. No context switch, no separate dashboard login, just more tool calls in the same conversation:

Tool	What it does
`nexusai_deploy_create`	Builds a container from the current project state and ships it, provisioning any declared database, worker, or storage resources
`nexusai_deploy_logs`	Streams build and runtime logs to confirm the deploy came up clean
`nexusai_deploy_health`	Checks whether the running service is passing health checks
`nexusai_deploy_scale`	Adjusts replica count or resources
`nexusai_deploy_rollback`	Reverts to a previous deployment if something breaks

A full headless round trip looks like this in practice:

Agent generates files → nexusai_builder_push → gets a preview URL
Person reviews it (optional) → agent calls nexusai_builder_pull if anything changed
Agent calls nexusai_deploy_create → app builds and gets a public HTTPS URL
Agent calls nexusai_deploy_logs and nexusai_deploy_health → confirms it's actually up
Days later, a bad change ships → agent calls nexusai_deploy_rollback → previous version is live again

At no point in that sequence does a browser dashboard have to open. It can, at any point, for a human who wants to look, but it is never a required step.

Governance doesn't disappear just because the dashboard does

A reasonable worry with headless workflows is losing visibility into what an agent actually did. NEXUS AI headless deployments use the same OAuth-scoped access tokens and role-based permissions as dashboard use, scoped to exactly the actions a given token is allowed to take. Every tool call an agent makes, pushes, pulls, deploys, scales, rolls back, is written to the audit log with the acting identity and a timestamp. A headless deployment is still a fully attributable one; it just doesn't require a person to be the one clicking the buttons.

Try it now: connect an MCP-compatible client to NEXUS AI and ask it to push a small app to a preview with nexusai_builder_push, then deploy it with nexusai_deploy_create, all from the same conversation.

Frequently asked questions

What is headless app deployment?

Headless app deployment is shipping and operating an application entirely through programmatic tool calls, with no person clicking through a web dashboard. An AI agent generates the code, previews it, deploys it, and manages it afterward using API or MCP calls end to end.

How is headless deployment different from using the AI App Builder in a browser?

The underlying platform is the same. The difference is who drives it. In the browser, a person opens the Builder, reviews the preview, and clicks Deploy. In a headless workflow, an MCP-compatible agent calls the same underlying actions, nexusai_builder_push for a preview, nexusai_deploy_create to ship it, as tool calls inside its own conversation, so no dashboard interaction is required at any point.

What does nexusai_builder_push actually return?

It returns a sessionId for the Builder session, a builderUrl for an instant browser preview, a filesCount confirming how many files were written, and a snapshotMessageId identifying that push as a restorable checkpoint.

Can nexusai_builder_pull lose an agent's own changes?

No. Pulling reads the latest snapshot, which includes both agent-pushed files and any browser-side edits layered on top. It does not discard prior pushes; each push remains a separate, restorable checkpoint in the session history.

Is a headless deployment less secure than a dashboard deployment?

No. Headless workflows authenticate with the same OAuth-scoped access tokens and role-based permissions as dashboard sessions, and every tool call is written to the audit log with the acting identity and timestamp, so a headless deployment is fully attributable after the fact.

NEXUS AI — AI-native cloud infrastructure · nexusai.run

Deploy from Claude Code to a live URL

Saif Ali — Thu, 03 Sep 2026 09:54:38 +0000

Deploy from Claude Code to a live URL

Published: September 2, 2026
Category: AI Deployments · MCP
Reading time: 6 minutes
Author: NEXUS AI Team

Claude Code can write a working app in a session. The gap is everything after the agent stops generating: a database, secrets, a public URL, backups, and a rollback path.

NEXUS AI is the deploy layer for that session. You add one MCP server, sign in once, and paste one prompt. The same agent that wrote the code calls nexusai_deploy_source. About five minutes later you have a live URL.

This is the Claude Code path. Cursor, Claude Desktop, and Codex use the same MCP server and the same sign-in. See Connect NEXUS AI MCP in your editor.

What you need

A NEXUS AI account (start free)
Claude Code installed and signed in
An app in a Git repo Claude Code can see (GitHub is the usual case)

No API key to copy. Claude Code runs an OAuth sign-in the first time it connects, and you approve exactly the access you want the agent to have.

1. Add the NEXUS AI MCP server

In the project directory:

claude mcp add --transport http nexus-ai https://mcp.nexusai.run/mcp

--transport http has to come before the server name. Without it, Claude Code treats the entry as a stdio command and the connection fails.

The first time an agent session uses the server, Claude Code opens a browser tab on mcp.nexusai.run, you sign in to NEXUS AI, and you approve the scopes. Claude Code stores the token locally, not in your repo, and refreshes it for you (access tokens last an hour). You can also start the sign-in by hand: run /mcp in a session, select nexus-ai, then Authenticate.

Approve only what the agent needs. To watch first, deployments:read and deployments:logs are enough. For the deploy in step 2, add deployments:create. Add secrets:manage when you want the agent to write secrets, and db:admin for database backups, restores, and applied schema fixes. Leave the delete scopes (deployments:delete, buckets:delete, volumes:delete, db:source:delete) off unless you specifically want them.

Share the server with a team. Add --scope project and Claude Code writes .mcp.json at the repo root:

{
  "mcpServers": {
    "nexus-ai": {
      "type": "http",
      "url": "https://mcp.nexusai.run/mcp"
    }
  }
}

Commit that file. No token goes in it. Each teammate does the OAuth sign-in once on their own machine.

Confirm it connected. Inside a session, /mcp should show nexus-ai as connected, not failed. Then check the identity:

Call nexusai_whoami and tell me which tenant I am connected to.

If it shows as failed, the usual causes are a missing --transport http, the wrong host, or a declined or expired sign-in. Re-run /mcp and choose Authenticate. To disconnect entirely, claude mcp remove nexus-ai.

2. Paste this prompt

Open Claude Code in the repo and send:

Deploy this repo to NEXUS AI with Postgres and Redis. Detect the framework and start command from the project. Wait until the deployment is healthy, then give me the public HTTPS URL, the deployment ID, and the masked database host. Do not write a Dockerfile unless the build fails.

What the agent should call:

nexusai_projects_list (or create a project)
nexusai_deploy_source with the Git URL, the detected framework, and services: ["postgresql", "redis"]
nexusai_deploy_status until healthy
nexusai_deploy_logs if the build fails

You did not open a cloud console. You did not write compose YAML. The agent already has the repo context.

Postgres and Redis run as sidecars on the NEXUS managed container platform, with DATABASE_URL and REDIS_URL injected automatically. If you target a single-container cloud runtime instead (App Runner, Cloud Run, Container Apps), Postgres becomes a managed instance and Redis is not available there.

If the app needs uploads, follow with:

Create a bucket called user-uploads, attach it to this deployment, and redeploy so the app gets S3_ENDPOINT, S3_BUCKET, S3_ACCESS_KEY, and S3_SECRET_KEY.

That is nexusai_bucket_create, nexusai_bucket_attach, then nexusai_deploy_redeploy. The attach step needs buckets:manage.

3. Operate from the same session

These are the next prompts worth saving.

Snapshot before a migration

Before you run the migration, take a Postgres backup of this deployment. If the migration fails, restore that backup and roll back the deploy.

Triage a 500

Tail the last 200 log lines for this deployment, name the failure, and fix it. If it is a missing secret, create it in the vault and redeploy.

Roll back

Snapshot Postgres, then roll this deployment back to the previous release. Confirm it is healthy.

Backups and rollback are safe operations. The tools that overwrite or delete data (nexusai_db_restore, nexusai_db_apply_fix, nexusai_deploy_delete, bucket and volume delete) carry a destructive hint, so Claude Code asks you to confirm each call before it runs. SQL that writes rows or changes schema also needs an explicit confirmed: true.

4. Optional: preview in the builder first

If you want a live preview link before production, ask Claude Code to push the current files with nexusai_builder_push, open the preview, then deploy. Pull builder-side edits back with nexusai_builder_pull. Same MCP server, no extra install.

Frequently asked questions

Does this work if the app was generated in this Claude Code session?

Yes. Push or commit so nexusai_deploy_source has a Git URL, or deploy from local source if you use that path. The agent already knows the framework, port, and start command.

How does authentication work? Is there an API key?

No static key. The MCP server uses OAuth with PKCE. Claude Code registers itself, opens a browser sign-in the first time it connects, and stores a short-lived token locally that it refreshes on its own. You approve the scopes during sign-in and can re-approve a wider set later by running /mcp and authenticating again. The personal access tokens at nexusai.run/settings/tokens are for the REST API, not the MCP server.

Is this an MCP gateway?

No. NEXUS AI is an app deploy platform that agents drive over MCP. It is not a gateway for hosting other MCP servers.

What does the live stack include?

App container, optional Postgres, MySQL, or Mongo, Redis, workers, volumes, S3-compatible buckets, HTTPS, logs, backups, and rollback. Full-stack deploys run on the NEXUS managed container platform. Single-container apps can target AWS App Runner, Google Cloud Run, or Azure Container Apps.

Can I do this from Cursor or Claude Desktop instead?

Yes. Same MCP URL, same OAuth sign-in. See Connect NEXUS AI MCP in your editor.

How do I cut off access?

claude mcp remove nexus-ai deletes the server and its stored token from that machine. Manage account tokens at nexusai.run/settings/tokens.

Deploy from Codex to a live URL

Saif Ali — Thu, 03 Sep 2026 09:53:27 +0000

Deploy from Codex to a live URL

Published: September 2, 2026
Category: AI Deployments · MCP
Reading time: 6 minutes
Author: NEXUS AI Team

Connect OpenAI Codex to NEXUS AI over MCP, deploy the repo you just worked on, and get a public HTTPS URL with Postgres. Then back up, tail logs, and roll back without leaving the terminal.

Codex is good at reading a repo and changing it. Production still needs a database, secrets, a URL, and a rollback path. NEXUS AI is the deploy layer for that session: one MCP server, one OAuth sign-in, one prompt, and the same agent that edited the code calls nexusai_deploy_source.

This is the Codex path. See also Deploy from Claude Code and Deploy from Cursor — same MCP server, same tools.

What you need

A NEXUS AI account (start free)
Codex CLI installed and signed in to OpenAI
An app in a Git repo Codex can see

No API key to paste. Codex runs an OAuth sign-in against the server and stores the token in its own credential store.

1. Add the NEXUS AI MCP server

Two commands:

codex mcp add nexus-ai --url https://mcp.nexusai.run/mcp
codex mcp login nexus-ai

codex mcp add writes a [mcp_servers.nexus-ai] block to ~/.codex/config.toml. codex mcp login reads the server's OAuth metadata, opens a browser, and stores the access token — nothing lands in the config file or your shell history.

Prefer to edit the file yourself? Add this to ~/.codex/config.toml (global) or .codex/config.toml in the repo (project-scoped), then run codex mcp login nexus-ai:

[mcp_servers.nexus-ai]
url = "https://mcp.nexusai.run/mcp"

Approve only what the agent needs in the browser consent screen. deployments:read and deployments:logs to inspect. Add deployments:create to deploy, secrets:manage to write secrets, db:admin for backups and restores, buckets:manage for storage. Leave the delete scopes (deployments:delete, buckets:delete, db:source:delete) off unless you want them.

Confirm it connected:

codex mcp list

nexus-ai should show as authenticated. Then, in a session:

Call nexusai_whoami and tell me which tenant I am connected to.

If login failed, re-run codex mcp login nexus-ai. To remove the server, codex mcp remove nexus-ai.

2. Paste this prompt

In the repo, start Codex and send:

Deploy this repo to NEXUS AI with Postgres and Redis. Detect the framework and start command from the project. Wait until the deployment is healthy, then give me the public HTTPS URL, the deployment ID, and the masked database host. Do not write a Dockerfile unless the build fails.

What the agent should call:

nexusai_projects_list (or create a project)
nexusai_deploy_source with the Git URL, framework, and services: ["postgresql", "redis"]
nexusai_deploy_status until healthy
nexusai_deploy_logs if the build fails

No cloud console, no compose YAML. Codex already has the repo context.

Postgres and Redis run as sidecars on the NEXUS managed container platform, with DATABASE_URL and REDIS_URL injected automatically. On a single-container cloud target (App Runner, Cloud Run, Container Apps), Postgres becomes a managed instance and Redis is not available.

For uploads, follow with:

Create a bucket named user-uploads, attach it to this deployment, and redeploy so the app gets S3_ENDPOINT, S3_BUCKET, S3_ACCESS_KEY, and S3_SECRET_KEY.

That is nexusai_bucket_create, nexusai_bucket_attach, then nexusai_deploy_redeploy.

3. Operate from the same session

Snapshot before a migration

Before you run the migration, take a Postgres backup of this deployment. If the migration fails, restore that backup and roll back the deploy.

Triage a 500

Tail the last 200 log lines for this deployment, name the failure, and fix it. If it is a missing secret, create it in the vault and redeploy.

Roll back

Snapshot Postgres, then roll this deployment back to the previous release. Confirm it is healthy.

Backups and rollback are safe. The tools that overwrite or delete data (nexusai_db_restore, nexusai_deploy_delete, bucket and volume delete) carry a destructive hint, so Codex asks you to confirm each call. SQL that writes rows or changes schema also needs an explicit confirmed: true.

4. Optional: preview in the builder first

Ask Codex to push the current files with nexusai_builder_push to get a live preview URL before production, then deploy. nexusai_builder_pull brings builder-side edits back into the workspace. Same MCP server, no extra install.

Frequently asked questions

Does this work if Codex just generated the app?

Yes. Push or commit so nexusai_deploy_source has a Git URL, or use nexusai_builder_push for a preview first. The agent already knows the framework, port, and start command.

How does authentication work? Is there an API key?

No static key. The MCP server uses OAuth with PKCE. codex mcp login nexus-ai runs the browser sign-in and Codex stores a short-lived token in its credential store, refreshing it on its own. You approve the scopes during login. The personal access tokens at nexusai.run/settings/tokens are for the REST API, not the MCP server.

Where is the config stored?

~/.codex/config.toml for a global server, or .codex/config.toml in the repo for a project-scoped one. The [mcp_servers.nexus-ai] block only holds the URL; the token lives in Codex's credential store, not the file, so a project-scoped config is safe to commit.

Is this an MCP gateway?

No. NEXUS AI is an app deploy platform that agents drive over MCP. It is not a gateway for hosting other MCP servers.

What does the live stack include?

Claude Code or Cursor instead?

Same product, same MCP server, different client. See Deploy from Claude Code and Deploy from Cursor.

Deploy your Cursor app to production

Saif Ali — Thu, 03 Sep 2026 09:51:43 +0000

Deploy your Cursor app to production

Published: September 2, 2026
Category: AI Deployments · MCP
Reading time: 6 minutes
Author: NEXUS AI Team

Point Cursor at NEXUS AI over MCP. Deploy the app sitting in your editor. Get a public HTTPS URL with Postgres, then back up, tail logs, and roll back from chat.

Cursor is strong at generating and editing the app. Production still needs a database, secrets, a URL, and a rollback path. Vercel MCP will host a frontend. NEXUS AI deploys the full stack the agent just wrote: app, Postgres, Redis, storage, workers.

This is the Cursor path. Claude Code users should read Deploy from Claude Code to a live URL.

What you need

A NEXUS AI account (start free)
Cursor with Agent and MCP enabled
The project open in Cursor (a GitHub remote is the easy deploy source)

No API key to paste. Cursor runs an OAuth sign-in the first time it connects to the server, and you approve the access the agent gets.

1. Add NEXUS AI in Cursor

Option A — project file (recommended)

Create .cursor/mcp.json in the repo:

{
  "mcpServers": {
    "nexus-ai": {
      "url": "https://mcp.nexusai.run/mcp"
    }
  }
}

No token in the file, so it is safe to commit. When Cursor first uses the server it opens a browser sign-in on mcp.nexusai.run; you approve the scopes and Cursor stores the token itself.

Option B — Cursor Settings

Cursor Settings, MCP, Add server. Same URL. Complete the OAuth sign-in when prompted.

Option C — all projects on this machine

Put the same JSON in ~/.cursor/mcp.json.

Approve only what the agent needs. Start with deployments:read and deployments:logs to inspect. Add deployments:create to deploy, secrets:manage to let it write secrets, db:admin for backups and restores, and buckets:manage if it will create a storage bucket. Leave the delete scopes (deployments:delete, buckets:delete, db:source:delete) off unless you want them.

Reload MCP in Cursor Settings and confirm nexus-ai is green. If the sign-in never completes, the server stays unauthenticated and every tool call fails; re-open the auth screen from the MCP settings row.

2. Send this prompt in Agent

With the project open:

Deploy this Cursor project to NEXUS AI with Postgres and Redis. Use the GitHub remote as the source. Detect the framework and start command from the repo. Wait until it is healthy, then give me the public HTTPS URL and the deployment ID. If there is no Git remote, push the current files to the NEXUS AI Builder for a preview first (nexusai_builder_push), then deploy.

What should happen:

Cursor reads the repo it already has open
nexusai_deploy_source with the Git URL, framework, and services: ["postgresql", "redis"] (or nexusai_builder_push then deploy)
nexusai_deploy_status until healthy
nexusai_deploy_logs on failure

You stay in the editor. No second terminal for Docker, no dashboard click-path unless you want one.

For uploads, add:

Create a bucket named user-uploads, attach it to this deployment, and redeploy so the app gets S3_ENDPOINT, S3_BUCKET, S3_ACCESS_KEY, and S3_SECRET_KEY.

3. After it is live

Save these as follow-ups in the same Agent thread.

Secret the app is missing

The app needs STRIPE_SECRET_KEY. Create it in the NEXUS vault for this deployment and redeploy. Do not print the value.

Backup, then migrate

Snapshot Postgres for this deployment. Then I will run the migration. If the logs show a migration error, restore the snapshot and roll back.

Why is it 500

Tail runtime logs, identify the exception, patch the file in this workspace, and redeploy.

Roll back

Roll this deployment back to the previous release and confirm it is healthy.

Backups and rollback are safe. The tools that overwrite or delete data (nexusai_db_restore, nexusai_deploy_delete, bucket and volume delete) carry a destructive hint, so Cursor asks you to confirm each call. Do not approve deployments:delete on a token you use against production.

4. Builder preview without leaving Cursor

nexusai_builder_push sends the current files into the NEXUS AI Builder and returns a preview URL. Use it when you want a shareable snapshot before production. nexusai_builder_pull brings builder-side edits back into the Cursor workspace.

That is the Cursor loop: generate in the IDE, preview on a URL, deploy the same tree.

Frequently asked questions

Will this replace Vercel for a Cursor frontend?

Use Vercel if you only need the UI. Use NEXUS AI when the Cursor app needs Postgres, Redis, workers, or file uploads in the same deploy.

Do I need the NEXUS CLI?

No. The MCP server is enough. The nexus CLI is optional if you prefer a terminal.

How does authentication work? Is there an API key?

No static key. The MCP server uses OAuth with PKCE, and Cursor runs the sign-in in a browser on first connect. You approve the scopes there and can re-approve a wider set later from the MCP settings row. The personal access tokens at nexusai.run/settings/tokens are for the REST API, not the MCP server.

Can the rest of the team deploy from Cursor too?

Yes. Commit .cursor/mcp.json with just the url. Each person signs in once on their own machine.

How is this different from other Cursor MCP hosts?

Other services focus on hosting the MCP server or the frontend. NEXUS AI's job is the production stack after the URL is up: managed databases, backups, rollback, secrets, and the same tools from the dashboard, CLI, and MCP.

Claude Code instead of Cursor?

Same product, different client. See Deploy from Claude Code to a live URL.

The best way to deploy an HTML website and API to the cloud

Saif Ali — Sat, 22 Aug 2026 18:11:14 +0000

The best way to deploy an HTML website and API to the cloud

Published: August 10, 2026
Category: Deployments · Fundamentals
Reading time: 6 minutes
Author: NEXUS AI Team

Short answer: if your HTML and your API are small enough to ship together, put them in one server (a static folder plus a few routes) and deploy that as a single container. It is one URL, no CORS, no second bill, and it fits on a free tier. Split them into two separately-hosted services only when you actually need independent scaling or a different tech stack for each side. This post covers both paths, with the commands for each.

The three ways people actually do this

1. One server, two jobs. An Express, FastAPI, or Flask app that serves your index.html (and any CSS/JS) as static files from one route, and your API as JSON routes on the same port. One deploy, one URL, one process. This is the right default for a portfolio site, an internal tool, a small SaaS MVP, or anything where the frontend and backend ship together.

2. Two hosts, one app. The HTML lives on a static host (a CDN edge network), the API lives on a separate compute host, and the frontend calls the API's URL over HTTPS with CORS enabled. This is the classic Vercel/Netlify-plus-Render/Railway pattern. It buys you independent scaling and a CDN for the static assets, at the cost of two dashboards, two bills, and a CORS config to maintain.

3. Raw cloud primitives. S3 or Cloud Storage plus a CDN in front for the HTML, then Lambda/Cloud Functions or a VM for the API. Full control, the most setup work, and you own the plumbing (TLS certs, IAM, deploy scripts) yourself.

Most people asking "what's the best way to deploy my HTML site and API" have something closer to option 1 in mind and don't need the operational overhead of options 2 or 3 yet.

	Setup time	Cost to start	Scaling	Best for
One server, two jobs	~5 minutes	Free tier fits	Vertical, then horizontal	MVPs, internal tools, small apps
Two hosts, one app	~15–30 minutes	Two free tiers, or one paid	Independent per side	Apps that outgrew #1
Raw cloud primitives	Hours to days	Pay-as-you-go	Fully manual	Teams with existing cloud infra

Option 1: deploy HTML + API together as one container

This is the fastest path and the one this section walks through end to end using NEXUS AI, which auto-detects a static folder next to an API server and builds a single production Dockerfile for it — no Dockerfile required on your side.

Project layout

my-app/
  public/
    index.html
    style.css
    app.js
  server.js        ← serves /public and the /api routes
  package.json

// server.js
const express = require("express");
const path = require("path");
const app = express();

app.use(express.static(path.join(__dirname, "public")));
app.use(express.json());

app.get("/api/health", (req, res) => res.json({ status: "ok" }));

app.get("/api/items", (req, res) => {
  res.json([{ id: 1, name: "First item" }]);
});

const port = process.env.PORT || 3000;
app.listen(port, () => console.log(`Listening on ${port}`));

Deploy it

Install the CLI and log in:

curl -fsSL https://nexusai.run/install.sh | bash    # Linux
curl -fsSL https://nexusai.run/install-mac.sh | bash # macOS
nexus auth login

Push the repo to GitHub, then deploy:

nexus deploy source \
  --repo https://github.com/you/my-app.git \
  --name my-app \
  --provider docker \
  --framework express \
  --wait

NEXUS AI builds a production image, opens a public HTTPS URL through Traefik, and streams build logs while it works. When it finishes, https://my-app.nexusai.run serves the HTML at / and JSON at /api/* from the same origin. No CORS headers needed because it is one origin.

If your HTML has no server logic at all (pure static, no API in the same process), skip the Express wrapper and deploy the folder directly:

nexus deploy source \
  --repo https://github.com/you/my-static-site.git \
  --name my-static-site \
  --provider docker \
  --framework static \
  --wait

NEXUS AI detects the plain index.html and serves it with nginx.

Add environment variables and a custom domain

nexus secret create DATABASE_URL "postgres://..." --project my-app
nexus domain add my-app yourdomain.com
nexus domain verify my-app <domain-id>

That covers the common case: one small app, one deploy, one bill, free tier eligible.

Option 2: split the static site and the API into two services

Reach for this once the frontend and backend genuinely need to scale, deploy, or fail independently — a marketing site that gets Hacker-News-front-page traffic spikes while the API stays flat, or a frontend team shipping on a different cadence than the backend team.

Deploy the API on its own:

nexus deploy source \
  --repo https://github.com/you/my-api.git \
  --name my-api \
  --provider docker \
  --framework express \
  --wait

Deploy the static HTML as a second service in the same project (this needs a plan with more than one active deployment — see the FAQ below):

nexus deploy source \
  --repo https://github.com/you/my-frontend.git \
  --name my-frontend \
  --provider docker \
  --framework static \
  --wait

Point the frontend's fetch calls at the API's public URL, and enable CORS on the API for the frontend's origin:

// my-api/server.js
const cors = require("cors");
app.use(cors({ origin: "https://my-frontend.nexusai.run" }));

// my-frontend/app.js
fetch("https://my-api.nexusai.run/api/items")
  .then((r) => r.json())
  .then(render);

Each service now scales, redeploys, and rolls back independently:

nexus deploy scale my-api 3

You can also mix providers here: keep the static frontend on a CDN-first host (Vercel, Netlify, GitHub Pages) for free and put only the API on NEXUS AI. Point the frontend's NEXT_PUBLIC_API_URL (or equivalent) at the NEXUS AI URL and enable CORS the same way.

FAQ

Do I need to write a Dockerfile for a plain HTML site?
No. NEXUS AI detects an index.html with no build manifest and serves it with nginx automatically. If you have a build step (Vite, React, Vue), it detects the framework and runs the production build instead.

My API needs a database. Does that change the deploy?
No extra service to wire up separately. Add --services postgresql (or mysql, mongodb, redis) to the same nexus deploy source command and NEXUS AI provisions the database alongside your app in the same deploy, with DATABASE_URL injected automatically.

Can I use a custom domain instead of the .nexusai.run subdomain?
Yes, on any paid plan. nexus domain add <deployment> yourdomain.com, then verify the DNS record NEXUS AI gives you.

Is there a free tier?
Yes. The Free plan includes one active deployment on the NEXUS AI managed cloud, no credit card required — enough for the single-server pattern in Option 1. Running the two-service split in Option 2 on NEXUS AI for both halves needs a plan that allows more than one active deployment (Pro and above); running just the API on NEXUS AI Free while the static frontend sits on a separate free static host works within the Free plan.

Does this handle HTTPS automatically?
Yes. Every deployment gets a public HTTPS URL through Traefik by default, and custom domains get certificates provisioned automatically once DNS verification passes.

Can I deploy from the GitHub UI instead of the CLI?
Yes. Connect your GitHub account from the NEXUS AI dashboard, select a repo and branch, and enable auto-deploy so every push to that branch redeploys automatically.

What if I'd rather describe the app in plain English and skip writing server.js myself?
Use the AI App Builder instead: describe the HTML site and the API you want in chat, review the generated files and live preview, then deploy from the same dashboard.

For an app with a real database, background workers, and file storage in addition to the HTML + API pair, see From v0 prototype to production database in 5 minutes and Deploy a full-stack Python app with Postgres, Redis, and workers in 5 minutes.

Start free.

Enterprise vibe coding: the governance framework for shipping AI-generated apps to production

Saif Ali — Sat, 22 Aug 2026 18:09:02 +0000

Enterprise vibe coding: the governance framework for shipping AI-generated apps to production

Published: August 22, 2026
Category: Enterprise · AI Deployments
Reading time: 9 minutes
Author: NEXUS AI Team

Gartner forecasts that 40% of new enterprise production software will be built using vibe coding techniques by 2028. A 2026 scan of more than 1,400 live vibe-coded applications found that 65% already had a security issue, and 58% shipped with at least one critical vulnerability. Those two numbers describe the same industry moving in opposite directions at once: adoption is outrunning governance.

This post covers what a governance framework for enterprise vibe coding actually looks like, the five controls it needs, and where most teams get it wrong.

What is enterprise vibe coding?

Enterprise vibe coding is the practice of using natural-language prompts to generate application code, then governing that code through mandatory review, access control, and audit before it reaches production, rather than letting it ship straight from a prompt to a live endpoint. The term (coined by Andrej Karpathy in early 2025) originally described a fast, low-friction way for one person to build a prototype. What "enterprise" adds is the governance layer prototyping was never built for: staging environments, encrypted secrets, role-based access, and a record of who approved what.

That distinction matters because the adoption curve and the risk curve are not moving together.

The governance gap, in three numbers

40% of new enterprise production software will be built using vibe coding techniques by 2028, according to Gartner's May 2025 report "Why Vibe Coding Needs to Be Taken Seriously," as reported by CIO Dive.
65% of vibe-coded production applications had a security issue, in a 2026 scan of more than 1,400 live apps by the API security firm Escape.tech, reported via a Cloud Security Alliance research note.
58% of those same applications shipped with at least one critical vulnerability, including hardcoded secrets and exposed personally identifiable information, per the same research note.

Enterprises are not waiting for a governance model before they start vibe coding internal tools, dashboards, and customer-facing features. They already have prototypes running in places IT never reviewed: a developer's laptop, a personal cloud account, a container nobody on the security team knows exists.

The fix is not to slow down adoption. It is to give the workflow teams already use a governed path to production, instead of asking them to abandon a workflow that is, by every account, faster than what it replaced.

What "enterprise-ready" actually requires

Most vibe coding tools are optimized for the first 90% of the problem: turning a prompt into working code fast. Enterprise readiness is almost entirely about the remaining 10%, the part that happens after the code works and before it is trusted with real users or real data.

Capability	Consumer vibe-coding tools	Enterprise-ready platform
Where it runs	Vendor-hosted, shared infrastructure	Your own AWS, Google Cloud, or Azure account
Secrets handling	Frequently hardcoded into generated code	Encrypted secrets vault, injected at runtime
Change review	Rare or none — the agent applies changes directly	Every schema and infrastructure change reviewed by a human before it ships
Access control	Single shared account, no role separation	Role-based access control (RBAC) with least-privilege defaults
Audit trail	Rare or none	Full audit log of every automated action, attributable to a user or agent
Rollback	Manual, if available at all	One-click versioned rollback
Data residency	Decided by the vendor	Decided by the customer (on-premises, private cloud, or hybrid)

None of these controls are exotic. They are the same controls that already exist for human-written code in any organization with a functioning SDLC. The gap is that most vibe coding tools were built for individual prototyping, where none of this mattered, and enterprises adopted them anyway because the alternative, a developer manually gluing infrastructure together, was slower.

A five-control governance framework

Enterprises that have gotten ahead of the governance gap generally converge on the same five controls, applied before code reaches a production endpoint:

Define which tools are approved, and for what. Not every vibe coding tool should be allowed to touch every kind of workload. Internal dashboards and low-risk operational tools are a reasonable starting point; anything touching regulated data (PHI, PCI, PII) needs a platform with compliance controls attached by default, not bolted on later.
Require human review before infrastructure or schema changes ship. An agent proposing a database migration or an IAM policy change is fine. An agent applying it unilaterally is how you end up as a statistic in the next vulnerability scan. Review gates are the single highest-leverage control in this list.
Put secrets in a vault, never in generated code. Hardcoded credentials are one of the most consistently identified issues in scans of AI-generated code. An encrypted secrets vault with runtime injection removes the failure mode entirely rather than relying on the agent to remember not to do it.
Log every automated action. If an agent deployed it, scaled it, or rolled it back, that action needs to be attributable and reviewable after the fact. Security and compliance teams cannot govern what they cannot see.
Deploy inside a perimeter you control. For regulated workloads especially, "which cloud account is this actually running in" needs a straightforward answer. Vendor-hosted, shared infrastructure makes that answer harder than it needs to be.

Organizations that put structured frameworks like this in place report meaningfully faster remediation when something does go wrong, without giving up the development speed that made vibe coding worth adopting in the first place.

How NEXUS AI implements each control

NEXUS AI extends the same natural-language workflow teams already use to generate an app through deployment, with these five controls attached by default:

Approved-tool boundary: the AI App Builder generates and verifies code in an isolated development sandbox before anything is deployed.
Review gates: the database intelligence layer lets an agent propose schema fixes from runtime logs, but every change is reviewed by a human before it is applied.
Secrets vault: every deployment gets an AES-256-GCM encrypted secrets vault, with values injected at runtime and never written into the container image.
Audit log: every automated action, by a user or an MCP-connected agent, is recorded and reviewable.
Your own cloud, or ours: NEXUS AI Enterprise deploys on-premises, inside your own AWS, Google Cloud, or Azure account, or in a hybrid mix of both. Shared, multi-tenant infrastructure is available but never mandatory.

See the full breakdown on the vibe coding for the enterprise page, or the compliance controls on the security and HIPAA and compliance pages if the workload touches regulated data.

Common mistakes enterprises make with vibe coding

Treating governance as a launch blocker instead of a default. Bolting review, secrets management, and audit logging onto an existing vibe-coded app after the fact is far more expensive than starting with a platform that ships them by default.
Banning the workflow instead of governing it. Prohibition policies get worked around. Teams that need to move fast will use an ungoverned tool on a personal account rather than wait for IT to approve a governed one. The fix is to make the governed path the fast path.
Assuming code review catches what secret scanning would. Human reviewers are good at logic and architecture; they are inconsistent at spotting a hardcoded API key in a 400-line diff. Automated secrets detection and a vault are not optional.
Skipping the audit log because "nothing has gone wrong yet." The value of an audit trail is realized entirely after something goes wrong. By then, it is too late to start logging.

FAQ

What percentage of AI-generated code has security vulnerabilities?
A 2026 scan of over 1,400 vibe-coded production applications by Escape.tech, reported via a Cloud Security Alliance research note, found that 65% had a security issue and 58% shipped with at least one critical vulnerability, including exposed secrets and personally identifiable information.

How much enterprise software will actually be vibe coded?
Gartner's May 2025 report "Why Vibe Coding Needs to Be Taken Seriously" forecasts that 40% of new enterprise production software will be built using vibe coding techniques by 2028.

Is vibe coding safe to use for production applications?
Not by default. Published scans of vibe-coded apps show high rates of security issues and critical vulnerabilities when code goes straight from prompt to production with no review layer. Enterprise vibe coding platforms close that gap with mandatory human review, an encrypted secrets vault, RBAC, and a full audit log before anything ships.

What does "vibe coding for the enterprise" mean, specifically?
It means giving teams that already use AI to generate application code a sanctioned, governed path to production, instead of prototypes running on laptops or personal cloud accounts outside IT review.

Does adding governance controls slow down vibe coding?
Not meaningfully, if the controls are built into the platform rather than added as a separate process. A review gate on infrastructure changes and an automatic secrets vault add seconds, not days, when they are part of the deploy workflow instead of a follow-up ticket.

The gap between vibe coding adoption and vibe coding governance is not going to close on its own. It closes when the platform generating the code is the same platform enforcing review, secrets management, access control, audit logging, and deployment into a cloud account the enterprise actually controls.

See vibe coding for the enterprise applied. Or talk to sales about a governed path to production for your team.

NEXUS AI RBAC Deep Dive

Saif Ali — Sat, 15 Aug 2026 14:45:44 +0000

RBAC deep dive: roles, scopes, and least privilege

Published: August 15, 2026

Category: Security · Platform

Reading time: 14 minutes

Author: NEXUS AI Team

A developer leaves the company on Friday. By Monday, their credentials still open three production deployments, two billing pages, and a secrets vault they haven't touched in four months.

That's not a people problem. That's an access model problem.

Role-Based Access Control (RBAC) is how NEXUS AI answers the question every engineering org eventually asks: who can do what, to which resources, and how do we prove it? This post goes deep the role hierarchy, how scopes layer on top of roles, how least privilege works in practice, and how to design an access model your team will actually maintain.

Why RBAC matters more as your team scales

When it's just you, every door being open is convenient. When you have a team of 12 across three environments, every door being open is a liability.

The breach surface for a SaaS product running on cloud infrastructure is rarely the infrastructure itself. It's the humans and automated systems that have standing access to it:

A contractor with admin access granted for a two week engagement and never revoked.
A CI/CD token with full secrets:write permission because it was "easier to set up that way."
A junior developer who can redeploy production because the staging role got copy-pasted.

NEXUS AI's RBAC system is designed to make the right permission easy to grant and hard to accidentally expand. Least privilege is the default, not a setting you have to configure.

The role hierarchy

NEXUS AI defines four built-in roles. They are ordered by permission level each role is a strict superset of the one below it.

Role	Who it's for	What it controls
Viewer	Stakeholders, auditors, QA observers	Read-only access to deployments, logs, and metadata
Developer	Engineers doing day-to-day deployment work	Deploy, redeploy, rollback; read secret names (not values)
Admin	Team leads, platform engineers	Full control of deployments, secrets, tokens, and members
Owner	Founder, CTO, or designated security lead	Everything Admin can do + delete the organization

One organization has exactly one Owner. Ownership can be transferred, but not duplicated. This prevents the "everyone is an Owner" pattern that makes incident response a guessing game.

Viewer

Viewers can observe nothing more.

✓ View deployment status (running, stopped, failed)
✓ Read build and runtime logs
✓ See deployment metadata (region, container count, uptime)
✓ View audit log summaries
✗ Trigger any action (deploy, redeploy, rollback, stop)
✗ See secret names or values
✗ Create or revoke Access Tokens
✗ Invite or remove team members

Use Viewer for: product managers monitoring deploy status, customer success checking uptime, external auditors reviewing activity logs, read-only access for contractors.

Developer

Developers can act on deployments. They cannot change platform configuration.

✓ Everything Viewer can do
✓ Deploy, redeploy, rollback, stop deployments
✓ View secret names (DATABASE_URL, STRIPE_KEY) never values
✓ Create Access Tokens scoped to deploy:read and deploy:write only
✗ Create, update, or delete secrets
✗ Create tokens with admin or secrets:write scope
✗ Invite or remove organization members
✗ View billing or usage data

A Developer can push code and redeploy. They cannot change the secrets their code reads. The separation is intentional: it means a Developer-level compromise cannot extract production credentials, only trigger a redeploy.

Admin

Admins own the platform configuration for an organization.

✓ Everything Developer can do
✓ Create, update, and delete secrets
✓ Create Access Tokens with any scope
✓ Invite members and assign roles (up to Admin)
✓ View and export audit logs
✓ Manage domains, billing, and usage
✗ Delete the organization
✗ Transfer ownership
✗ Grant Owner role to another member

Limit Admin to people who actually need to configure secrets or onboard team members. In a 10-person startup, that's usually two or three people. In a 100-person company, it's a dedicated platform team.

Owner

The Owner role is structurally different from Admin it's not just "more permissions," it's accountability. Only one member holds it, and it carries the ability to perform irreversible actions.

✓ Everything Admin can do
✓ Delete the organization and all its resources
✓ Transfer ownership to another Admin
✓ Access all historical audit logs (including deleted members)

The Owner should be the person who is accountable for the business not necessarily the most technical. At a startup, that's the founding engineer or CTO. At an enterprise, it's the platform owner or CISO-designated lead.

How scopes work

Roles define what a human can do. Scopes define what a token can do.

When a Developer (or Admin) creates an Access Token, they can grant that token any scope up to but not exceeding their own permissions. A Developer cannot create a token with secrets:write scope, because Developers cannot write secrets directly.

This is scope containment: tokens cannot be a privilege escalation vector.

The full scope table

Scope	Read/Write	What it permits
`deploy:read`	Read	View status, logs, metadata for deployments
`deploy:write`	Write	Create, redeploy, rollback, scale, stop deployments
`secrets:read`	Read	List secret names for a deployment (never values)
`secrets:write`	Write	Create, update, delete secrets
`tokens:read`	Read	List tokens and their metadata
`tokens:write`	Write	Create and revoke Access Tokens
`members:read`	Read	List organization members and their roles
`members:write`	Write	Invite, remove, and change roles of members
`billing:read`	Read	View usage statistics and invoices
`billing:write`	Write	Update billing plan and payment method
`logs:read`	Read	Read build logs, runtime logs, and audit logs
`admin`	All	Full access equivalent to Admin role

Scopes compose. A CI token for a deployment pipeline typically needs deploy:write and nothing else. A token for a read-only monitoring integration needs deploy:read and logs:read. An MCP integration for an AI agent doing deployment management might need deploy:read,deploy:write,logs:read.

Creating a precisely scoped token

# CI/CD: deploy-only, expires in 90 days
nexus token create \
  --name "github-actions-prod" \
  --scopes deploy:write \
  --expires 90d

# Monitoring integration: read-only, no expiry (rotate quarterly via calendar)
nexus token create \
  --name "datadog-integration" \
  --scopes deploy:read,logs:read

# AI agent with deployment management access
nexus token create \
  --name "claude-mcp-agent" \
  --scopes deploy:read,deploy:write,logs:read \
  --expires 30d

# Admin token for a one time onboarding script (delete immediately after use)
nexus token create \
  --name "onboarding-script-2026-04-21" \
  --scopes admin \
  --expires 1d

The last example a short-lived admin token for a specific script, destroyed after use is exactly how temporary elevated access should work. No standing privileged access. No "just in case" tokens that accumulate over months.

Least privilege in practice

Least privilege is not a policy you write. It's a discipline you build into your provisioning process. Here's what it looks like in a real NEXUS AI team across three common scenarios.

Scenario 1: Onboarding a new backend engineer

Wrong approach:

New hire → Admin role → "they'll need it eventually"

Right approach:

New hire → Developer role
Week 1: pair with an Admin for any secrets work
Month 3: reassess do they actually need Admin? (usually no)

The Developer role covers 95% of what an active engineer does: deploy, redeploy, check logs, rollback a bad release. Secret creation is rare and can go through an Admin without slowing anyone down.

Scenario 2: Setting up a GitHub Actions pipeline

Wrong approach:

nexus token create --name "github-actions" --scopes admin
# Stored in GitHub secrets as NEXUS_API_KEY

Right approach:

# One token per environment, deploy:write only
nexus token create --name "github-actions-staging" --scopes deploy:write --expires 90d
nexus token create --name "github-actions-prod" --scopes deploy:write --expires 90d

# Store each in the corresponding GitHub environment secret
# github.com/org/repo → Settings → Environments → staging → NEXUS_API_KEY
# github.com/org/repo → Settings → Environments → production → NEXUS_API_KEY

Environment scoped tokens mean a staging pipeline compromise cannot touch production. The deploy:write scope means the pipeline can redeploy but cannot read or modify secrets.

Scenario 3: Granting an external contractor temporary access

Wrong approach:

Contractor → Admin role → "we'll remove it when they're done"
(They're done. It's still there. Six months later: breach.)

Right approach:

# Invite as Viewer they can observe, not act
nexus member invite contractor@agency.com --role Viewer

# If they need to trigger deploys, create a scoped token with explicit expiry
nexus token create \
  --name "contractor-agency-q2-2026" \
  --scopes deploy:write \
  --expires 30d

# Deliver the token via a secure channel. Calendar reminder for 29 days out.
# At project end: revoke the token and remove the member
nexus token revoke tok_01HX9...
nexus member remove contractor@agency.com

The token expires automatically even if you forget. The member removal is still important it cleans up the audit trail and signals a clean handoff.

Resource-level access: deployments and projects

Roles apply at the organization level by default. But NEXUS AI also supports project-scoped membership isolating access to a subset of deployments within an organization.

# Add a Developer to a specific project only
nexus project member add \
  --project payments-service \
  --email engineer@company.com \
  --role Developer

# They can now deploy payments-service/* deployments
# They cannot see auth-service/*, user-service/*, or any other project

Project-scoped access is useful for:

Regulated workloads — your payments team accesses the payments project; your analytics team accesses the analytics project. No overlap.
Multi-tenant organizations agencies managing deployments for multiple clients. Each client's project is isolated.
Contractor access — limit a vendor to exactly the project they're working on.

Organization-level Admins retain visibility across all projects. Project-scoped Developers cannot see outside their project boundary.

RBAC and AI agents

NEXUS AI's 37 MCP tools for Claude and AI agents operate under the same RBAC model as human callers. A token issued to an AI agent carries exactly the same scope enforcement no exceptions.

This matters because AI agents tend to be given more access than they need "because it's easier." An agent with admin scope that goes wrong is a full organization compromise. An agent with deploy:read that goes wrong reveals status information and nothing else.

Designing safe agent access

Read-only diagnostic agent — Claude inspects logs, checks deployment health, surfaces anomalies:

nexus token create \
  --name "claude-diagnostic" \
  --scopes deploy:read,logs:read \
  --expires 7d

The agent cannot deploy, rollback, or change anything. It observes and reports.

Deployment automation agent — Claude reacts to CI signals and triggers redeployments:

nexus token create \
  --name "claude-deploy-agent" \
  --scopes deploy:read,deploy:write,logs:read \
  --expires 30d

The agent can act on deployments. It cannot touch secrets, billing, or team membership.

Incident response agent — Claude triages a production incident, can rollback if needed:

# Short-lived, manually issued during an incident
nexus token create \
  --name "claude-incident-2026-04-21" \
  --scopes deploy:read,deploy:write,logs:read \
  --expires 4h

4-hour expiry. The token disappears when the incident window ends. No standing elevated access for AI agents.

The rule: grant an AI agent the minimum scope it needs to complete its defined task. Then set an expiry that matches the task duration — not "never" because that's convenient.

What RBAC cannot do

Knowing the limits of any security control is as important as knowing what it covers.

RBAC does not protect against a compromised Owner account. The Owner role has full access. If an Owner's credentials are compromised, the attacker has full access. Protect Owner accounts with hardware MFA, not just TOTP.

RBAC does not prevent a Developer from logging sensitive data. If your application logs process.env.DATABASE_URL at startup, that value appears in runtime logs — which Developers can read. Secret management starts with application code discipline.

RBAC does not enforce network-level isolation. A Developer with deploy:write can push a container that opens a reverse shell. Pair RBAC with container security policies and network egress controls for workloads that require it.

RBAC does not replace secrets rotation. Least privilege reduces blast radius when a secret is compromised. Rotation reduces the window of exposure. Both are required for a complete security posture.

The access model audit

Run this quarterly. It takes 20 minutes and it will find something to fix every time.

# List all organization members and their roles
nexus member list

# List all active tokens with creation date and last-used date
nexus token list --show-last-used

# Check for tokens with no expiry
nexus token list --no-expiry

# Check for tokens unused in 30+ days
nexus token list --unused-since 30d

For each token unused in 30+ days: revoke it. For each admin-scoped token that isn't for a one-time script: replace it with narrower scopes. For each member at a role higher than their current responsibilities: downgrade it.

The goal is to reach a state where every active token has a name that explains exactly what it does, an expiry that matches how long it needs to exist, and the minimum scope to do its job.

RBAC and compliance

If you're in a regulated industry healthcare, fintech, legal — RBAC is table stakes for compliance. NEXUS AI's RBAC system maps directly to common control requirements:

Compliance requirement	NEXUS AI control
Least-privilege access	Role hierarchy + token scopes
Separation of duties	Developers cannot write secrets; Owners are unique
Access review	`nexus member list`, `nexus token list` for quarterly audits
Privileged access management	Admin and Owner roles with MFA enforcement
Access revocation on termination	`nexus member remove` + `nexus token revoke`
Audit trail	Append-only audit logs with actor, token ID, timestamp, and IP

Enterprise and Enterprise On-Prem plans include 90-day and indefinite audit log retention respectively. Logs are exportable to Datadog, Grafana, Splunk, or any SIEM via the audit log export API.

Checklist: production-grade RBAC setup

[ ] Assign roles at the minimum level needed start with Developer, escalate to Admin only when demonstrated necessary
[ ] No team member should have Owner role unless they're accountable for the organization
[ ] Every CI/CD pipeline uses a separate deploy:write token per environment
[ ] Every token has a name that identifies its purpose and a --expires flag
[ ] No admin-scoped tokens in standing use only for one-time scripts with 1-day expiry
[ ] AI agent tokens scoped to exactly what the agent does (not admin)
[ ] Quarterly access review: nexus token list --unused-since 30d and nexus member list
[ ] Project-scoped membership for workloads that should be isolated (payments, healthcare, multi-client)
[ ] Owner account protected with hardware MFA (YubiKey or equivalent)
[ ] Offboarding runbook: member remove + all associated tokens revoke, same day

Frequently asked questions

Can a Developer see their own Access Tokens after creation?

Token values are shown once at creation — never again. A Developer can list their tokens by name and ID (nexus token list --mine), but the token_value is never retrievable. If lost, rotate.

What happens to tokens when a member is removed?

Tokens are scoped to the organization, not to the member who created them. Removing a member does not automatically revoke their tokens. Run nexus token list --created-by email@company.com and revoke manually as part of offboarding. A future release will offer member-removal with automatic token revocation.

Can a Developer escalate their own role?

No. Role changes require Admin or Owner. A Developer cannot call any API endpoint that modifies their own or another member's role.

How does NEXUS AI handle role changes mid-session?

Role and scope changes take effect immediately. An active API session using a token that gets revoked will receive a 401 Unauthorized on the next call — there's no grace window for human sessions (only for the 5-minute deploy token rotation window).

Is there a way to grant time-limited elevated access without creating a token?

Not currently at the role level — role changes are persistent until manually reverted. Use a short-lived admin-scoped token for temporary elevated operations instead of upgrading a member's role. This keeps the audit trail cleaner and eliminates the "I forgot to downgrade them" failure mode.

We're on the Starter plan. Do we get RBAC?

Yes. All four roles and the full scope system ship on every plan, including Starter at $29/mo. Project-scoped membership and audit log export are Enterprise features.

What's next

Access control works best when it's boring when every token has a clear purpose, every role is appropriate, and your quarterly audit finds nothing to clean up. That state is achievable. It requires an initial setup investment of about two hours and 20 minutes of discipline every quarter.

Start with your CI/CD tokens. Replace any admin-scoped pipeline token with deploy:write. That one change eliminates your largest standing access risk.

For regulated workloads, compliance tooling, or teams larger than 20 engineers, the Enterprise plan adds SAML SSO, custom audit log retention, and dedicated security review. Reach out at nexusai.run.

Related reading:

Stop shipping secrets. Start using a vault.
MCP integration: 37 tools for Claude and AI agents
Audit logs and compliance: what gets recorded and why
How NEXUS AI deploys your app in under 5 minutes

Least privilege is not paranoia. It's the discipline that makes incidents containable.

NEXUS AI One-Prompt Deployment Is Here Just Describe It and Ship It

Saif Ali — Sat, 15 Aug 2026 14:37:32 +0000

One Prompt Deployment Is Here Just Describe It and Ship It

Tell it what you want. Watch it deploy.

Headline Options

One-Prompt Deployment Is Here Just Describe It and Ship It
Deploy With Words: Introducing One-Prompt Deployment
Forget the Config — Just Tell It What to Deploy

There's a version of deployment that feels like magic. You describe what you want — in plain English, in a single line — and your app is live. No YAML. No CLI flags. No digging through docs to remember what --replicas does in this context.

That version of deployment exists now. Meet One-Prompt Deployment.

What Is One-Prompt Deployment?

One-Prompt Deployment lets you trigger and configure deployments using natural language. Instead of writing pipeline configs or remembering command syntax, you just describe your intent:

"Deploy the latest build of the payments service to staging with 3 replicas and a 5-minute timeout."

That's it. The system interprets your intent, maps it to the right configuration, runs pre-flight checks, and ships it all without you touching a config file or terminal command.

It's not a chatbot wrapped around a deploy button. Under the hood, it's a structured inference layer that translates natural language into validated deployment operations, with full auditability and rollback built in.

Why We Built This

Deployment tooling has gotten incredibly powerful over the last decade but with that power came complexity. Kubernetes configs, Helm charts, custom CI/CD pipelines: each layer adds capability, but also adds surface area to learn, maintain, and debug.

We wanted to give developers the full power of that tooling without requiring them to become experts in every layer of it. One-Prompt Deployment is the result: a natural language interface that sits on top of your existing infrastructure and makes it approachable for everyone on the team.

What Makes It Different

It Moves at the Speed of Thought

The fastest interface is the one where you don't have to translate your intent into syntax. With One-Prompt Deployment, you describe what you want in natural language and the system handles the translation. In practice, this means going from "I want to deploy this" to "it's deployed" in under two minutes including the time it takes to type the prompt.

No more context-switching to look up CLI flags or YAML schema. No more copy-pasting config from a deployment that worked last time. Just describe it and ship it.

Works With Your Stack, Out of the Box

One-Prompt Deployment understands the vocabulary of your existing infrastructure. Connect it to your cloud provider, container registry, and environment configs, and it immediately knows the names of your services, your environment tiers, and your deployment conventions.

That means your prompts can be natural and specific: "Roll out the new auth service to production using the blue/green strategy" — and it knows exactly what "auth service," "production," and "blue/green" mean in your context. No training required, no custom setup beyond your existing connections.

Guardrails Built In — Not Bolted On

Natural language is flexible, which means there's room for ambiguity. We take that seriously. Before any deployment runs, the system surfaces a confirmation summary showing exactly what it understood and what it's about to do. You review, approve, and then it executes.

If something looks off at the pre-flight stage, it halts and explains why — with a suggested fix in plain language. And if a deployment does go wrong post-launch, automatic rollback restores your last stable state, no incident bridge required.

Unlocks Deployment for Your Whole Team

This is the one we're most excited about. Traditionally, production deployments are gatekept not because teams want them to be, but because the tooling is too complex for anyone outside of platform or DevOps to use safely.

One-Prompt Deployment changes that calculus. QA engineers can deploy to staging environments without waiting on a pipeline engineer. Product managers can trigger approved releases without opening a terminal. On-call rotations can use it to execute rollbacks without institutional knowledge of your infra.

Your deployment process doesn't have to be a bottleneck anymore.

Getting Started

Enabling One-Prompt Deployment takes about five minutes:

Navigate to Settings → Deployments → Prompt Mode in your dashboard
Connect your infrastructure integrations (cloud provider, registry, environments)
Run a test prompt to confirm your context is loaded correctly
Start deploying

Full documentation including prompt syntax tips, advanced configuration, and the API reference for programmatic prompt-triggered deployments is in our developer docs.

What's Coming Next

We're already building on this foundation. Next up: prompt-based deployment schedules ("deploy every Friday at 5pm if all tests pass"), multi-service orchestration prompts, and a prompt history log with diff views so you can audit exactly what was deployed and when.

We'd love your feedback as you use it. Join the conversation in our community Discord, open a GitHub Discussion, or just reply to this post. The best features we've built have come directly from developers telling us what's broken or missing — and this one is no different.

Ship the thing. We've handled the rest. 🚀

Author: [NEXUS AI Team]
Published: [8/15/2026]
Tags: deployments, developer tools, AI, natural language, CI/CD, new feature, engineering

Getting Started: NEXUS AI Connector on Claude

Saif Ali — Sat, 15 Aug 2026 14:30:38 +0000

Getting Started: NEXUS AI Connector on Claude

Your entire deployment platform, accessible through a single conversation.

Headline Options

Getting Started: NEXUS AI Connector on Claude
Control NEXUS AI With Claude — No Dashboard Required
Meet the NEXUS AI Connector: Deploy, Monitor, and Manage With Just a Prompt

What if you could deploy an app, check its health, spin up a database, and rotate a secret — all without leaving your AI assistant? No tab-switching, no dashboard hunting, no copy-pasting deployment IDs.

That's exactly what the NEXUS AI Connector for Claude makes possible. It connects your NEXUS AI account directly to Claude, giving you full control of your infrastructure through natural language. This guide walks you through getting set up and making your first prompt-driven deployment in under ten minutes.

What Is the NEXUS AI Connector?

The NEXUS AI Connector is an MCP (Model Context Protocol) integration that exposes your NEXUS AI platform — deployments, databases, secrets, domains, and more — as tools Claude can use on your behalf.

Once connected, Claude isn't just answering questions about your infrastructure. It's actually interacting with it: listing your running deployments, reading logs, scaling services, and executing the same operations you'd normally do through the dashboard or CLI.

Think of it as a natural language interface sitting on top of everything NEXUS AI can do.

What You Can Do With It

Here's a quick taste of what you can ask Claude once the connector is set up:

"List all my running deployments"
"Deploy the latest build of my API service to staging"
"Show me the last 50 runtime logs for the payments service"
"Create a new secret called DATABASE_URL for the production environment"
"Add a custom domain to my frontend deployment"
"Scale my backend service to 3 replicas"
"What's the health status of my production deployments?"

No syntax to memorize. No CLI to install. Just describe what you need.

Getting Started in 3 Steps

Step 1: Connect Your NEXUS AI Account

Open Claude and navigate to Settings → Connectors. Find the NEXUS AI Connector in the list and click Connect. You'll be prompted to authenticate with your NEXUS AI credentials — this uses a secure OAuth flow, so your credentials are never stored in the conversation.

Once authenticated, Claude will confirm that your account is linked and show you a summary of the resources it can access.

Tip: If you're on a Team or Enterprise plan, check with your org admin to make sure the NEXUS AI Connector is enabled in your workspace settings.

Step 2: Verify the Connection

Ask Claude something simple to confirm everything is working:

"What deployments do I have running right now?"

Claude will call the NEXUS AI API and return a list of your active deployments — names, statuses, providers, and environments. If you see your infrastructure listed back at you, you're good to go.

If Claude says it can't find any deployments, double-check that you connected the right NEXUS AI account and that your deployments are in a running or deploying state.

Step 3: Try Your First Prompt-Driven Action

Now for the fun part. Try a real operation:

"Deploy nginx:latest to port 80 in my development environment."

Claude will use the NEXUS AI Connector to kick off the deployment, then confirm what it's doing before executing. Once it's underway, you can follow up:

"What's the status of that deployment?"
"Show me the build logs."
"Is it healthy yet?"

Claude handles the back-and-forth with the API so you can stay in the conversation flow instead of jumping to the dashboard.

A Few Things Worth Knowing

Actions that modify your infrastructure require confirmation. Before Claude executes anything that changes state — deploys, scales, deletes, or modifies secrets — it will summarize what it's about to do and ask you to confirm. This is intentional. You stay in control.

Sensitive values are protected. When you ask Claude to create or update secrets, it will execute the operation but will never display secret values in the conversation. What goes into NEXUS AI stays in NEXUS AI.

Your logs and metrics are available inline. Ask Claude to pull logs mid-conversation and it will surface them directly — no need to open a separate terminal or dashboard tab. You can filter by log type, limit line counts, or ask Claude to highlight errors for you.

Everything is auditable. Every operation Claude performs via the connector maps to a real NEXUS AI API call. Your audit trail in NEXUS AI reflects all activity, whether it was initiated through the dashboard, CLI, or Claude.

What's Possible When You Put It Together

Once you're comfortable with the basics, the connector really shines in more complex workflows:

Debug faster: Ask Claude to pull logs, identify errors, propose a fix, and redeploy — all in a single conversation thread
Incident response: In a live incident, describe the symptoms and ask Claude to check deployment health, pull recent logs, and execute a rollback if needed
Onboarding: New engineers can interact with production-adjacent environments without needing to learn every CLI tool in your stack
Routine ops: Automate repetitive deployment checks or environment refreshes by describing what you need rather than scripting it

Ready to Try It?

The NEXUS AI Connector is available now. Head to your Claude settings, connect your account, and start your first session. The full list of supported operations — deployments, databases, secrets, domains, logs, health checks, and more — is documented in our connector reference docs.

If you run into anything unexpected, drop a message in our community Discord or open a support ticket directly from your NEXUS AI dashboard.

Your infrastructure is one prompt away. 🚀

Author: [Saif Ali]
Published: [4/20/2026]
Tags: NEXUS AI, Claude, MCP, connector, deployments, developer tools, getting started, AI infrastructure

NEXUS AI - Claude Code Tutorial

Saif Ali — Sun, 09 Aug 2026 13:30:56 +0000

Most Claude Code tutorials stop at "here's how to install it." That's like teaching someone to drive by showing them the ignition. This Claude Code tutorial goes further — you'll use it to build a real AI-powered app from scratch and deploy it to production, step by step.

By the end you'll have a working document Q&A API and a live deployment URL. The whole thing takes about an afternoon.

What Claude Code actually is (and why it's different)

Claude Code is Anthropic's AI coding agent that runs in your terminal. Unlike copilot-style tools that suggest individual lines inside an editor, Claude Code operates at the project level — it reads your entire codebase, understands how files relate to each other, and makes multi-file changes with full context.

The practical difference: you describe what you want to build, and Claude Code writes the code, runs commands, fixes errors, and iterates — without you switching between a chat window and your editor. It's AI-augmented development where the AI is a collaborator in your actual workflow, not a suggestion box beside it.

What makes it powerful for AI app development specifically:

It can generate boilerplate for FastAPI, Express, or any framework in seconds
It writes tests alongside the code it generates
It catches its own mistakes by running the code and reading error output
It handles the tedious parts (CI config, requirements.txt, test scaffolding) while you focus on the actual problem

Getting started: install and configure Claude Code

Install

npm install -g @anthropic-ai/claude-code

Requires Node.js 18+. Verify:

claude --version

Authenticate

claude

On first run, Claude Code opens a browser window to authenticate with your Anthropic account. Once authenticated, it drops you into an interactive session in your current directory.

Your first command

Navigate to an empty project folder and try:

mkdir my-ai-app && cd my-ai-app
claude

In the Claude Code prompt:

> Scaffold a FastAPI project with a single /health endpoint, a requirements.txt, and a .gitignore

Claude Code will create the files, show you what it's doing, and confirm. This is the core interaction pattern: describe the outcome, let it execute.

Build a real AI app with Claude Code

We're building a document Q&A API — you upload a text document, ask questions about it, and get answers grounded in the document's content. It's a practical RAG (retrieval-augmented generation) pattern used in real products.

Step 1 — Scaffold the project

In your Claude Code session:

> Create a FastAPI app for document Q&A. The app should:
> - Accept a POST /upload endpoint that takes a text file and stores it in memory
> - Accept a POST /ask endpoint that takes a document_id and a question, then answers using OpenAI gpt-4o-mini
> - Return answers in JSON with the answer text and a confidence field
> - Include a requirements.txt with fastapi, uvicorn, openai, and python-multipart

Claude Code will generate the full project structure:

my-ai-app/
├── main.py
├── requirements.txt
├── .gitignore
└── README.md

It writes the entire main.py — endpoints, in-memory document store, OpenAI call — in one pass.

Step 2 — Run it and fix errors

> Run the app locally with uvicorn and show me any errors

Claude Code executes uvicorn main:app --reload, reads the output, and if there are import errors or missing packages it fixes them automatically. This loop — run, read error, fix — is where Claude Code earns its keep. You don't context-switch; it just handles it.

Step 3 — Add real retrieval (not just stuffing the whole document)

The naive version sends the entire document to the model on every question. That breaks on large files and wastes tokens. Ask Claude Code to improve it:

> The current /ask endpoint sends the full document to OpenAI on every request.
> Refactor it to:
> - Split documents into 500-token chunks on upload
> - Use cosine similarity on TF-IDF vectors to find the top 3 relevant chunks
> - Only send those 3 chunks to OpenAI as context
> - Use numpy and sklearn for the vector operations

This is multi-file, multi-concept work. Claude Code will update main.py, add sklearn and numpy to requirements.txt, and implement the chunking + retrieval logic coherently. It understands that changing the upload flow affects the query flow and handles both.

Step 4 — Write tests

> Write pytest tests for both endpoints. Include:
> - A test that uploads a sample document and verifies the document_id is returned
> - A test that uploads a document, then asks a question whose answer is clearly in the document
> - A test that asks about a document_id that doesn't exist and expects a 404
> Mock the OpenAI call so tests don't need a real API key

Claude Code generates test_main.py with the exact structure you described, uses pytest-mock for the OpenAI mock, and adds the test dependencies to requirements.txt.

Run them:

> Run the tests and fix any failures

Claude Code runs pytest, reads the output, and iterates until they pass. The critical detail: it doesn't just generate tests and hand them back — it runs them and closes the feedback loop.

The CLAUDE.md file: your project's AI instruction layer

One of the most underused Claude Code features is CLAUDE.md — a file in your project root that Claude Code reads at the start of every session. Think of it as a permanent briefing document for your AI collaborator.

Create one:

> Create a CLAUDE.md for this project that documents:
> - The tech stack (FastAPI, OpenAI, sklearn)
> - The coding conventions we used (snake_case, type hints everywhere, docstrings on public functions)
> - The test setup (pytest, mock OpenAI calls)
> - What the /upload and /ask endpoints do

From this point on, any new Claude Code session on this project starts with full context. You don't re-explain the stack every time.

A good CLAUDE.md includes:

# Project: Document Q&A API

## Stack
- FastAPI + Uvicorn (Python 3.11)
- OpenAI gpt-4o-mini for generation
- sklearn TF-IDF + cosine similarity for retrieval
- pytest + pytest-mock for testing

## Conventions
- Type hints on all function signatures
- Snake_case everywhere
- Docstrings on all public functions

## Architecture
- Documents stored in-memory (dict keyed by UUID)
- Chunks: 500 tokens, 50-token overlap
- Top 3 chunks retrieved per query

## Running locally
uvicorn main:app --reload --port 8000

## Running tests
pytest -v

Deploy to production with the NEXUS AI CLI

Your app is built and tested. Now get it live — no Dockerfile required.

NEXUS AI detects your framework, builds the container for you, and deploys it. You push source code; NEXUS AI handles everything from there.

Step 5 — Push source to GitHub

Initialize a repo and push:

git init
git add .
git commit -m "initial: document Q&A API"
gh repo create my-ai-app --public --source=. --push

Or push to an existing repo. The only requirement is that your requirements.txt is at the project root — NEXUS AI uses it to detect that this is a Python app.

Step 6 — Install the NEXUS AI CLI

# Linux
curl -fsSL https://nexusai.run/install.sh | bash

# macOS
curl -fsSL https://nexusai.run/install-mac.sh | bash

Verify:

nexus --version

Step 7 — Deploy from source

# Log in to NEXUS AI
nexus auth login

# Deploy directly from your GitHub repo — no Docker required
nexus deploy source \
  --repo https://github.com/your-org/my-ai-app \
  --name doc-qa-api \
  --port 8000 \
  --provider gcp_cloud_run

# Add the OpenAI key as an encrypted secret
nexus secret create OPENAI_API_KEY --deployment doc-qa-api

# Attach a custom domain
nexus domain add api.yourcompany.com --deployment doc-qa-api

NEXUS AI clones your repo, detects the Python/FastAPI framework, builds a production container image, and deploys it. Within 2–3 minutes you have a live URL with TLS and autoscaling. Stream logs to verify:

nexus deploy logs doc-qa-api --follow

Automate deploys with GitHub Actions

Ask Claude Code to write the CI/CD config:

> Write a GitHub Actions workflow that redeploys the NEXUS AI deployment on every push to main.
> Use NEXUSAI_TOKEN as a secret. The deployment name is doc-qa-api.

Claude Code generates a complete .github/workflows/deploy.yml. The workflow calls nexus deploy redeploy doc-qa-api — NEXUS AI pulls the latest source, rebuilds the container, and rolls it out. Every push to main goes to production automatically.

Advanced Claude Code patterns for AI development

Multi-file refactoring

Claude Code handles refactors that would take hours manually. Example:

> The document store is currently an in-memory dict. Refactor it to use Redis so documents
> persist across server restarts. Update all references, add redis to requirements.txt,
> and update the CLAUDE.md architecture section.

It updates main.py, requirements.txt, and CLAUDE.md in one coherent pass — and since NEXUS AI builds from source, you just push the changes and redeploy.

Debugging without context-switching

When something breaks in production:

nexus deploy logs doc-qa-api --tail 50

Copy the error, paste it into Claude Code:

> Getting this error in production logs: [paste error]
> Find the root cause and fix it.

Claude Code reads the relevant code, identifies the issue, and applies the fix — all without you manually tracing through stack traces.

Using Claude Code for code review

Before opening a PR:

> Review the changes in git diff HEAD~1 for:
> - Security issues (injection, hardcoded secrets, unsafe deserialization)
> - Missing input validation on the API endpoints
> - Performance issues in the chunking logic

Claude Code runs the diff and produces a structured review with specific line references.

Common Claude Code mistakes to avoid

Giving vague prompts. "Make this better" produces mediocre output. "Refactor the chunking function to reduce memory allocation by processing tokens in a streaming fashion instead of loading the full document" produces a specific, actionable change.

Not using CLAUDE.md. Without it, you re-explain your stack every session. Ten minutes setting it up saves hours over the life of a project.

Accepting the first output blindly. Claude Code is fast, not infallible. Run the tests after every significant change. When they fail, let Claude Code fix them — that feedback loop is what makes it reliable.

Letting it over-engineer. Claude Code will sometimes propose abstractions you don't need. If you asked for a simple endpoint and got a three-layer architecture with an abstract repository pattern, push back: "Simplify this — no abstraction layers, just the endpoint and direct database calls."

Not scoping the context. In very large codebases, claude in the root directory gives it the whole repo. For a focused change, navigate to the relevant subdirectory first. Smaller context = more precise output.

Frequently asked questions

Does Claude Code work with languages other than Python?

Yes. Claude Code works with any language — TypeScript, Go, Rust, Ruby, Java. The same patterns apply: scaffold with a prompt, run it, let Claude Code fix errors. The CLAUDE.md approach works especially well in polyglot repos where you need to document which parts use which language.

Is Claude Code safe to run on production codebases?

Claude Code asks for confirmation before writing files or running commands. You control what it executes. For sensitive production repos, review the proposed changes before confirming — Claude Code shows you a diff before applying it. Never give it credentials directly; use environment variables and secrets managers.

How is Claude Code different from GitHub Copilot?

Copilot autocompletes individual lines and functions inside an editor. Claude Code operates at the project level in the terminal — it understands the full codebase, can run code, read test output, and make coordinated multi-file changes. They're complementary: Copilot for keystroke-level suggestions, Claude Code for larger tasks.

Can I use Claude Code without an Anthropic account?

No. Claude Code requires an Anthropic API key or Claude.ai Pro/Max subscription. Usage via the API is billed based on token consumption. The claude.ai subscription tiers include a monthly usage allocation.

What's the best way to handle large codebases?

Use .claudeignore (same syntax as .gitignore) to exclude directories that aren't relevant to your current task — node_modules, dist, venv, build artifacts. This keeps Claude Code's context focused on what matters and reduces token usage.

What you built

Start to finish: a document Q&A API scaffolded by Claude Code, with chunked retrieval, pytest coverage, and a live deployment on NEXUS AI — all without writing a Dockerfile or touching a browser.

That's AI-augmented development in practice. Claude Code handled the scaffolding, boilerplate, tests, and debugging loop. You handled the architecture decisions and product requirements. The result ships faster and has better test coverage than the same work done manually.

The NEXUS AI CLI handles the deployment side of this workflow. Install it, run nexus auth login, and your next Claude Code-built app is one command away from production.