Deploy AI agents

Run MCP connectors for your clients.

Writing the connector isn't the hard part, that's a day of work with a template you already trust. The hard part is running it for thirty or a hundred clients at once: keeping each client's secrets apart, giving each one its own domain and sign-in, shipping an update without a support ticket from everyone else, and reading the right logs when one client's connector breaks. DenkOps is built around one deploy per client, so none of that has to be something you build yourself.

Start on DenkOps →
01 · One template, many clients

One codebase.
One deploy per client.

The pattern that scales is simple: write the connector once, then deploy it once per client, each in its own slot with its own config. Nothing about one client's data, secrets or traffic ever shares a process with another client's deploy. Cramming many clients into a single running connector turns it into a multi-tenant system you now have to build, secure and debug by hand, that's not what a slot is for.

# one connector template, one config folder per client
$ ls clients/
acme/ globex/ initech/
 
git repo (template) ──┬── acme config → DenkOps deploy → https://acme-mcp.denkops.app
├── globex config → DenkOps deploy → https://globex-mcp.denkops.app
└── initech config → DenkOps deploy → https://initech-mcp.denkops.app

Same source, same tools, three separate slots. Adding client 51 means adding one more config and one more deploy, not touching the 50 that already work.

02 · Isolated by default

A leak in one client
never touches another.

Secrets & environment

Own env,
per client.

Each client's deploy gets its own environment variables. Update one client's API key and redeploy that one project, the other 49 never see the change and never see the key.

Custom domain

mcp.client-domain.com,
not a shared subdomain.

Point a client's own domain at their connector's deploy and DenkOps issues the certificate automatically. Their URL looks like theirs, not like a reseller shelf of lookalike subdomains.

OAuth & access policy

Own sign-in,
own access list.

Each connector runs its own OAuth (Google, GitHub or Microsoft) and its own access policy, public, limited to named emails, or kept to a workspace. One client's access list can't leak into another's.

Logs

Own log stream,
per deploy.

Every deploy has its own logs. Debugging Acme's connector means reading Acme's logs, not grepping a shared stream for the right tenant ID at 11pm.

03 · Predictable cost at scale

Flat per slot.
No per-request math.

One client, one deploy, one slot. Pricing is per slot, not per request or per tool call, so the bill scales with the number of clients you run, not with how often any of them happen to call a tool that week.

ClientsSlotsMonthly cost
55€39
1010€64
2525€139
5050€264
100100€514

Flat per slot, no per-request billing to model out in advance, cancel monthly. Full breakdown on pricing.

04 · Ship and update from git

Update one client
without touching the rest.

Each client connector is its own project in your CI. Mint a connection token from the dashboard's Connect page, scoped and pinned to that one client's project, store it as a GitHub Actions secret, and push. The workflow packs the repo and redeploys that client, and only that client.

A bug fix or a new tool rolls out to one client at a time, on your schedule, not to all of them at once because a shared connector got rebuilt.

# .github/workflows/deploy.yml, per client repo/project
on: { push: { branches: [main] } }
 
- run: npx -y @denkopsai/mcp deploy
env:
DENKOPS_TOKEN: ${{ secrets.DENKOPS_TOKEN }}
→ live at https://acme-mcp.denkops.app
05 · Roll back per client

One bad deploy,
one client affected.

Every deploy is versioned with time, actor and commit. If an update to one client's connector breaks something, roll that client's slot back to the last healthy version in one click on the dashboard, or say "rollback" and let your agent call the matching MCP tool from inside that project's session. The other 49 client connectors are separate deploys, so they're untouched.

06 · One control room

Fifty connectors.
One dashboard.

Isolation between clients doesn't mean losing track of them. One DenkOps workspace lists every client connector you run, with owner, member and viewer roles plus per-project overrides, so a contractor can get access to three client connectors without seeing the other forty-seven.

FAQ

Can I run one connector for 50 clients with different configs?

You can, but the recommended and safest pattern is one deploy per client instead: each gets its own slot, its own secrets, its own domain, its own OAuth and its own logs. That keeps the blast radius of any one client's bug, leak or outage at zero for the other 49.

How are each client's secrets kept separate?

Each client's deploy has its own environment. You set that client's secrets on that project and redeploy it, they're never shared with or visible to another client's deploy.

Can each client have their own domain?

Yes. Point a client's own domain at their connector's deploy and DenkOps issues the certificate automatically.

Can I deploy from GitHub?

Yes. Mint a connection token scoped and pinned to that client's project from the dashboard's Connect page, store it as a GitHub Actions secret, and run npx @denkopsai/mcp deploy on push.

How fast can I roll a client back?

One click on the dashboard, or one instruction to your agent over MCP, rolls that client's slot back to the last healthy version from its deploy history. No rebuild, and no effect on any other client.

What does it cost at 100 clients?

The same flat per-slot pricing as everything else on DenkOps: €39 for the first 5 slots, €5 for each slot after that. 100 always-on client connectors, one slot each, is €514 a month, no per-request math and no surprise invoice from a busy week.

← Deploy an MCP server · Capabilities · Pricing

Start on DenkOps →