This is week 4 of Build with CloudHike, a weekly series where we build a small, real-world app with an AI coding agent and let the agent set up the backend. Disclosure: I built CloudHike, so keep that in mind.

New here? Week 1 built a referral waitlist, week 2 moved slow AI work into background jobs with signed webhooks, and week 3 built a file-sharing app with presigned uploads. Each post stands on its own, so you can start right here.

The earlier weeks mostly used Cursor or Claude Code. That's fine when you stick to one editor. The moment you open the same repo in VS Code one day, Codex the next, and Windsurf on a teammate's machine, you suddenly have three places to paste keys, three slightly different MCP configs, and a quiet fear that an agent with deploy access might also be able to wipe the project.

This week is about that problem. We'll connect Codex, VS Code, Windsurf and Gemini CLI (plus the Cursor and Claude Code setups from earlier weeks) to one CloudHike workspace, point them all at the same project, run the built-in setup_backend prompt, pull the real docs with get_docs, and look at the safety model that makes this sane: the key can create and deploy, and nothing can be deleted through MCP.

Every config snippet and prompt below comes from the live MCP docs and Build with AI pages.

What we're building

Not a new product this week. A small Next.js app called multi-agent-notes, one CloudHike project behind it, and the same backend reachable from every editor you actually use:

  • One workspace API key from Connect MCP, shared across editors
  • Editor configs for Codex, VS Code (secret-input), Windsurf and Gemini CLI, with the Cursor and Claude Code snippets for anyone catching up
  • The built-in setup_backend prompt to provision Postgres (and only what the app needs) in one go
  • get_docs so the agent reads CloudHike's Markdown docs before it writes code
  • A proof pass from a second editor: same project id, same tables, same .env variable names, no secrets printed in chat
  • The delete rule: create and deploy are allowed; deleting a project or service stays in the dashboard

Here's how the pieces map:

  • One remote MCP server at https://cloudhike.dev/api/mcp (Streamable HTTP, nothing to install)
  • One workspace key (icu_...) as Authorization: Bearer ...
  • One project with the services your app needs, paid from one credit balance

Normally every AI editor is its own silo: its own secrets file, its own half-remembered setup, and no shared view of what was deployed. Here the editors are different; the backend is not.

What you need

  • A CloudHike account. Every new account gets $10 in free credits (eligible accounts, once per inbox, valid for 90 days), plus an extra $5 with the code TUBEGURUJI5, and no card is needed. The Free plan allows 2 projects, which is plenty for this.
  • At least one of: Codex, VS Code (Copilot Chat in Agent mode), Windsurf or Gemini CLI. Cursor and Claude Code work too if that's what you already have from weeks 1 to 3.
  • Node.js, for a small Next.js app.

Step 1: Create the workspace key (once)

In the CloudHike dashboard, open Connect MCP in the sidebar (https://cloudhike.dev/dashboard/coding-agent). Pick an editor and click Copy with key. The first time, that creates your workspace API key and gives you a snippet with the key already filled in.

A few things the docs make clear about this key:

  • It is a workspace key, not a single-project token. The same key works in every editor you configure.
  • Revoke on that page disconnects every editor at once. New key means pasting the new snippet again.
  • Treat it like a password. Keep it out of files you commit.
  • The same key can also drive the workspace prompt flow for tools that don't speak MCP yet. Prefer MCP when the editor supports it.

You only do this step once per workspace. The rest of the article is pasting the right shape of config into each editor.

Step 2: Scaffold a tiny app 

npx create-next-app@latest multi-agent-notes cd multi-agent-notes

Open that folder in whichever editor you're starting with. We want a real repo so setup_backend has somewhere to write .env.local, and so a second editor can open the same files and prove it's the same backend.

Step 3: Connect each editor

Replace icu_your_api_key with your key, or use Copy with key in the dashboard, which fills it in. The server name is cloudhike everywhere.

Codex (~/.codex/config.toml)

Codex keeps the secret in an environment variable instead of the config file:

# 1. Add this line to your shell profile (~/.zshrc or ~/.bashrc): # export CLOUDHIKE_API_KEY="icu_your_api_key" # 2. Add this to ~/.codex/config.toml: [mcp_servers.cloudhike] url = "https://cloudhike.dev/api/mcp" bearer_token_env_var = "CLOUDHIKE_API_KEY"

Open a new terminal so the variable is set, then run codex mcp list to check it.

VS Code (.vscode/mcp.json)

VS Code is the odd one out in a good way. It asks for the key the first time and keeps it in secret storage, so the config file itself is safe to commit:

{ "inputs": [ { "type": "promptString", "id": "cloudhike-key", "description": "CloudHike.dev API key", "password": true } ], "servers": { "cloudhike": { "type": "http", "url": "https://cloudhike.dev/api/mcp", "headers": { "Authorization": "Bearer ${input:cloudhike-key}" } } } }

Use Copilot Chat in Agent mode after it prompts for the key.

Windsurf (~/.codeium/windsurf/mcp_config.json)

Windsurf uses serverUrl instead of url:

{ "mcpServers": { "cloudhike": { "serverUrl": "https://cloudhike.dev/api/mcp", "headers": { "Authorization": "Bearer icu_your_api_key" } } } }

Gemini CLI (~/.gemini/settings.json)

Gemini CLI uses httpUrl:

{ "mcpServers": { "cloudhike": { "httpUrl": "https://cloudhike.dev/api/mcp", "headers": { "Authorization": "Bearer icu_your_api_key" } } } }

Cursor and Claude Code (if you're catching up)

Claude Code

claude mcp add --transport http --scope user cloudhike https://cloudhike.dev/api/mcp \ --header "Authorization: Bearer icu_your_api_key"

Run /mcp inside Claude Code to check that it's connected.

Cursor (~/.cursor/mcp.json)

{ "mcpServers": { "cloudhike": { "url": "https://cloudhike.dev/api/mcp", "headers": { "Authorization": "Bearer icu_your_api_key" } } } }

Open Cursor Settings → MCP and look for the green dot.

Notice the small differences: Cursor uses url, Windsurf uses serverUrl, Gemini CLI uses httpUrl, Codex uses bearer_token_env_var, and VS Code uses ${input:cloudhike-key}. Same server, same key, different client shapes. After saving, restart or reload the editor so the tools show up.

Step 4: Confirm the tools are there

In the editor you just configured, ask:

List the cloudhike MCP tools you can see. For each one, say whether it changes anything. Do not call any tool yet.

You should see the set from the MCP docs. Grouped the useful way:

Read-only

  • list_projects — your projects and their ids
  • get_project — a project and the status of each service
  • wait_for_services — waits up to 50 seconds, then reports status
  • get_environment — the project's .env (or format: "names" for names only, no secrets)
  • list_tables / describe_table / query_database — schema and read-only SQL (one statement, READ ONLY transaction, up to 500 rows, 10 second timeout)
  • list_storage_files — folders and files in the project's bucket
  • get_docs — any docs page as Markdown

Can change things

  • create_project — 2 to 40 characters, follows your plan's project limit
  • deploy_services — postgres, auth, storage, redis, jobs or email, with the same plan and billing checks as the dashboard (already-deployed services come back as exists)
  • execute_sql — Pro only, marked destructive, so your editor asks before running it; whole script in one transaction

What you will not see is anything that deletes a project or a service. That's the point of Step 8.

If the editor shows no cloudhike tools: restart or reload after saving the config. In Claude Code run /mcp, in Codex run codex mcp list, in Cursor check Settings → MCP. A 401 means the key was replaced or revoked — copy the snippet again from the Coding agent page.

Step 5: Run setup_backend (or the equivalent prompt)

In editors that show MCP prompts as slash commands, CloudHike offers a built-in setup_backend prompt. Run it and point it at this app.

If your editor doesn't surface MCP prompts, paste this instead (it's the setup prompt from the MCP docs):

Use the cloudhike MCP tools to set up CloudHike.dev as the backend for this app.

Read the app first and deploy only the services it needs. Put the .env into the app's git-ignored env file without showing me the values, then read the matching docs with get_docs and write the code that connects each service.

For this notes app, be specific so it doesn't deploy everything:

Use the cloudhike MCP tools to set up the backend for this app. It's a tiny personal notes app with a title and body per note.

Create a CloudHike project called "multi-agent-notes" and deploy postgres only. Wait until it's ready. Put the .env into .env.local, make sure it's git-ignored, and don't show me any secret values. Then call get_docs for the postgres page so you know how to use it. Don't write app code yet. Just tell me which services are running and which variable names are in .env.local.

Behind the scenes that walks the same tools the earlier weeks used by hand:

  1. create_project (or list_projects if it already exists)
  2. deploy_services for Postgres
  3. wait_for_services
  4. get_environment written into .env.local (ask for format: "names" when you only want names)
  5. get_docs for the Postgres page as Markdown

The server also exposes each docs page as a resource (cloudhike://docs/...), so some editors can attach the page directly instead of calling the tool.

Step 6: Let get_docs drive the code

Now that Postgres is up, paste:

Call get_docs for "postgres". Using node-postgres and only what that page describes, add a migration script in this repo that creates a notes table: id (uuid, default gen_random_uuid()), title (text), body (text), created_at. Create the pool once in lib/db.ts from DATABASE_URL, keep it on globalThis so hot reloads reuse it, and use max 5 connections. Run the migration with DIRECT_URL if .env.local has it, otherwise DATABASE_URL. Then use describe_table to show me the notes table. Do not print any secret values.

Why get_docs instead of "you know how Postgres works"? Because the page the agent pulls is your CloudHike Postgres page: connection pooler vs DIRECT_URL, the recommended pool size, SSL, the Free-plan idle behaviour. The code that follows matches the product you actually deployed, not a generic tutorial the model memorised.

Same safety model as weeks 1 to 3: query_database is always read-only, execute_sql is Pro-only and needs approval, and schema changes belong in repo migrations so they're reviewed and repeatable.

Optional UI so there's something to click:

Add a /notes page that lists notes newest first and a small form to create one (title + body) through a POST /api/notes route that inserts with node-postgres. Keep it minimal.

Step 7: Open the same repo in a second editor

This is the week-4 payoff. Close the first editor (or leave it), open multi-agent-notes in a different one you configured in Step 3, and ask:

Use list_projects to find the project named multi-agent-notes. Then get_project on it, get_environment with format "names", list_tables, and describe_table for notes. Tell me the project id, which services are ready, which env variable names exist, and the notes columns. Do not print secret values. Do not deploy or create anything.

You should get the same project id, the same ready services, the same variable names, and the same notes columns. That is the whole idea: Codex, VS Code, Windsurf, Gemini CLI, Cursor and Claude Code are different agents; CloudHike is one backend.

If the second editor can't see the tools, you're usually one reload away. If it can see tools but not the project, you're on a different workspace key — go back to Connect MCP and make sure every editor got the current key.

Step 8: Why no MCP tool can delete anything

The MCP security section is short and worth reading in full. The rules that matter when several agents share one key:

  • The key can create projects, deploy services and read keys. Nothing can be deleted through MCP. Deleting projects and services stays in the dashboard.
  • get_environment returns secrets so the agent can write your env file. The server tells agents to write them only to the git-ignored env file and never to repeat them in chat. Every fetch is written to the audit log as environment.agent-fetch.
  • All tools follow your plan limits and rate limits, exactly like the dashboard (requests limited to 120 per minute; database tools to 60 per 10 minutes).
  • VS Code's secret-input config is safe to commit; the other examples live in your home folder.
  • On every plan, query_database runs in a READ ONLY transaction. On Pro, execute_sql can change data or schema, runs in one transaction, is marked destructive so the editor asks first, and every run is audited as postgres.sql-write.

There's a parallel story on the non-MCP path: the per-project agent token from Copy prompt on the Overview tab can only download that project's .env. It cannot deploy, delete or change anything. Reset or revoke it from the dashboard when a pasted prompt might have leaked. Prefer MCP with the workspace key when your editor supports it; keep the project token for tools that only paste prompts.

So "any agent" does not mean "any blast radius." Several editors can build on the same project. None of them can remove it over MCP.

What CloudHike handled

Look back at what you didn't do: you didn't make a new backend per editor, you didn't copy connection strings between machines by hand, and you didn't give any agent a delete button.

One workspace key gave every editor:

  • the same remote MCP server and the same project,
  • setup_backend (or the equivalent prompt) to deploy and write .env.local without printing secrets,
  • get_docs so the code followed the real Postgres page,
  • read-only tools (list_projects, get_project, list_tables, describe_table, query_database) to prove the second editor was looking at the first editor's work,
  • a hard line that deletes stay in the dashboard.

Everything shows up in one dashboard and comes out of one credit balance. If you outgrow Free, Pro is $10/month with $10 of usage credits included every month and 10 projects, and Scale is $29.99/month with unlimited projects. The details are on the plans and billing page.

Your turn

Pick the two editors you actually switch between. Paste the configs from Step 3, run the setup_backend flow once, then do the proof pass from the second editor. If you want a longer checklist, the MCP docs also show how to poke the server with npx @modelcontextprotocol/inspector over Streamable HTTP.

👉 Start free at cloudhike.dev. You get $10 in credits at signup, plus $5 more with code TUBEGURUJI5, no card required.

Next week: members-only SaaS with real auth flows. Email verification, password reset, GitHub/Google sign-in through the shared OAuth app, HTTP-only cookie sessions, and the sites users can return to. Follow along so you don't miss it.

If you try this one, tell me in the comments which pair of editors you connected, or where a config file bit you. I read every comment.