NEXUS AI

I want to be upfront: Railway and Render are solid products. If you're a developer who deploys apps manually and wants a good experience, either of them is a fine choice.

I built NEXUS AI for a different use case.

The shift I'm betting on: a growing share of apps are being generated by AI tools (Claude Code, Cursor, v0, Bolt, Lovable). The developer's role is moving from writing code line-by-line to directing an agent that writes the code, and then needing that code shipped.

For that workflow, the existing platforms have a gap:

They don't talk to your AI agent. Railway and Render have no MCP support. Your Claude or Cursor agent can write code, but it can't deploy it, check logs, back up the database, or roll back a broken deploy. You have to switch contexts every time.

They don't do full-stack in one operation. Most platforms deploy containers. You add a database separately. You configure workers separately. Storage is another step. NEXUS AI deploys the whole stack together: app, database, workers, buckets, volumes, all connected, in one operation.

They weren't designed for AI-generated code specifically. AI tools generate apps that assume infrastructure: they reference DATABASE_URL, they expect Redis to be on an internal hostname, they assume S3-compatible storage exists. NEXUS AI's deployment model matches those assumptions out of the box.

I'm not trying to replace Railway for developers who love it. I'm building for the developer who generated their app in 45 minutes with Claude and wants to ship it in the same session, with their agent handling the ops loop.

That's a real use case. It's growing fast. And I think it deserves a platform built specifically for it.

nexusai.run if you want to try it. Free tier, no credit card.

Something I shipped recently that I think more developers should know about: the NEXUS AI MCP server.

Here's the practical version of what it enables.

You're building with Claude Code. You finish a feature. Normally you'd commit, push, wait for CI, then go check your deployment platform to see if it worked. Maybe tail logs in a separate tab. Maybe open a DB console if something breaks.

With the NEXUS AI MCP server connected, Claude handles all of that.

Setup takes about 2 minutes. Add this to your Claude Desktop config:

```json

{

  "mcpServers": {

    "nexus-ai": {

      "url": "https://api.zollo.live/mcp",

      "headers": { "Authorization": "Bearer YOUR_TOKEN" }

    }

  }

}

```

Generate a token at nexusai.run/app/tokens. That's it.

What Claude can now do for you:

Deploy from your repo: "Deploy my main branch to production" → Claude calls nexusai_deploy_source, builds from GitHub, gives you a live URL.

Add a database: "Spin up a Postgres database for this deployment" → Claude calls nexusai_managed_db_create, attaches it, injects the connection string.

Watch for errors: "Are there any errors in my app logs?" → Claude calls nexusai_deploy_logs, reads the output, surfaces anything worth fixing.

Back up before a migration: "Back up the database before I run this migration" → Claude calls nexusai_db_backup, confirms the snapshot is ready, then you proceed.

Roll back if something breaks: "The last deploy broke something, roll it back" → Claude calls nexusai_deploy_rollback, restores the previous version.

Fix a schema issue: "My app is throwing a column not found error, fix it" → Claude reads the log, proposes the DDL fix via nexusai_db_propose_fix, you approve, Claude applies it via nexusai_db_apply_fix.

The loop closes: Claude writes the code and Claude manages the deployment. You stay in the conversation.

NEXUS AI has a free tier (one deployment, no credit card). The MCP server works on the free tier.

Full setup guide: nexusai.run/docs

One pattern I kept seeing after launching NEXUS AI:

Developers would deploy an AI-generated app, the app would hit a database error at runtime, and then they'd be stuck in a loop of reading logs, opening a DB console, trying to figure out what went wrong with the schema.

AI tools are great at generating application code. They're less great at getting the database schema exactly right on the first try. Missing indexes, wrong column types, a migration that assumed a column existed when it didn't.

So I built what I'm calling a database intelligence layer directly into the platform.

Here's what it does:

Schema inspection. You can inspect your tables, columns, types, and indexes directly from the dashboard or via MCP. No need to open a separate DB console.

Query preview. Before running a query against your production database, you can preview it in a sandboxed environment with a statement timeout. No accidental full-table scans.

AI-proposed fixes from runtime logs. This is the part I'm most excited about. When your app throws a database error, Claude can inspect the runtime log, propose a DDL fix (the actual SQL to correct the schema), and apply it after you review and approve it. The change is audited.

The workflow looks like this: app throws a runtime error → Claude reads the log via nexusai_deploy_logs → Claude proposes a fix via nexusai_db_propose_fix → you review it → Claude applies it via nexusai_db_apply_fix.

It closes the loop between code generation and production reliability in a way I haven't seen on other platforms.

Still iterating on this. The approval step is intentional: I don't want AI applying DDL changes to production databases without a human in the loop. But the proposal and review flow is fast enough that it doesn't slow you down.

If you're building with Claude Code or Cursor and hitting schema issues in production, this is what NEXUS AI was built for.

How it started: I was on my third startup. The product was the easy part. Every time I needed to deploy something new — a new service, a new environment, a side project — I'd spend half a day reconstructing the same AWS setup I'd done four times before.

ECS cluster. Task definition. ECR repo. IAM roles. Load balancer. TLS cert. GitHub Actions YAML that slowly grew from 20 lines to 80 lines and became load-bearing infrastructure I was afraid to touch.

I'm not a DevOps engineer. I'm a product person who can write code. And I kept running into the same wall: the actual deployment stack required a completely different skillset from building the product.

I started NEXUS AI because I wanted to type one command and have a running app on AWS. That's it. That was the entire original requirement.

---

What I built

NEXUS AI is a CLI-first deployment platform. You point it at a GitHub repo (or any source), it detects your runtime, builds a container, provisions the cloud infrastructure in your own AWS/GCP/Azure account, and returns a live URL.

```bash

nexus deploy source \

--repo https://github.com/you/app \

--name my-app \

--provider aws_ecs_fargate

```

No Dockerfile. No YAML. No cloud console. Under 5 minutes for the first deploy, 60–90 seconds for every deploy after.

The key architectural decision I made early: deploy into the customer's cloud account, not a shared NEXUS AI environment. This was harder to build. It required solving IAM, cross-account provisioning, and a lot of AWS-specific plumbing. But it meant customers keep data sovereignty — which opened up regulated industries (healthcare, fintech) that would never trust shared infra.

That decision also meant we couldn't be "just another Render or Railway." We're competing differently.

---

The hardest part to build

Framework detection sounds trivial. It's not.

When someone points us at a repo, we need to figure out: what runtime, what version, what start command, what port, what build steps. package.json is straightforward. A monorepo with three services and a custom build script is not.

We got this wrong several times in ways that were silent and confusing. The container would build fine but start wrong. We added a build log stream early — nexus deploy logs --follow — mostly so I could debug our own detection failures faster.

The other hard part: making rollback feel safe. Our first version of rollback worked but required knowing the previous image tag. Nobody knows that. We rebuilt it to store versioned deployment state and let you roll back with just nexus deploy rollback --deployment-id <id>. That took two weeks of work that users now never think about. Which is the point.

---

What's working

The MCP integration surprised me. We shipped 37 MCP tools that let Claude and other AI agents deploy, scale, and rollback apps through natural language. I expected this to be a novelty feature that a few power users would play with.

It turns out a meaningful portion of our users are building AI-native products — apps where Claude or another agent is orchestrating infrastructure as part of a larger workflow. The MCP integration went from "interesting experiment" to a real acquisition channel. Anthropic listed us in their MCP directory. That sent a wave of signups we weren't expecting.

The blog has also started compounding. We published SEO content targeting specific deployment queries — "deploy Node.js app without Dockerfile", "CI/CD alternatives", "deploy without DevOps" — and the organic traffic is now meaningful. AEO (optimizing for AI answers, not just Google) is something I've been thinking about a lot. When someone asks Claude or Perplexity "how do I deploy a Node.js app," I want NEXUS AI in that answer. We're getting there.

---

What's not working (yet)

Enterprise is slower than I expected. We have the right features — customer-owned cloud, HIPAA-aligned controls, tenant isolation, audit logs — but the sales cycle is long and we don't have enough case studies yet. We've been doing founder-led sales which doesn't scale. This is the thing I'm thinking about most right now.

Pricing is also something I've revised twice. We started too low (bad signal, attracted the wrong users), went up, and are still figuring out where the Pro tier ceiling is. The $149/month Pro plan feels right for SaaS teams. Enterprise is custom. But the gap between those two is wide.

---

What I'd do differently

Start with a tighter ICP. We initially said "any developer deploying to the cloud." That's everyone and no one. We've found our best customers are either:

1. Solo founders and small SaaS teams who know they need AWS/GCP but don't want to become AWS experts

2. AI product builders who want managed infra they don't have to think about

The compliance/regulated segment is real but takes longer to convert. If I were starting over, I'd spend the first six months exclusively on segment 1 and 2 before touching enterprise.

The other thing: I should have launched on Product Hunt earlier. We held back waiting until the product felt "ready." The Product Hunt audience is forgiving of rough edges and gives you feedback you can't get any other way. We're launching our MCP integration on Product Hunt soon — better late than never.

---

Where we're at

We're post-launch, pre-Series A, growing mostly through content and word of mouth. The dev.to and Hacker News posts have driven more signups than anything we've paid for. The MCP integration is our biggest differentiator right now and I think we're early in what that category becomes.

If you're building something that needs a deployment layer — or if you've built a deployment layer yourself and want to compare notes — I'd genuinely love to hear from you in the comments.

And if you want to try NEXUS AI: [nexusai.run](https://nexusai.run). Free to start, no credit card required.

---

What questions do you have? Happy to go deep on anything — the technical architecture, the pricing decisions, the compliance angle, or the MCP integration. Ask in the comments.