DEV Community: CloudHike Team

Build a referral waitlist with your AI agent: Postgres, Auth, Redis and email over one MCP connection

CloudHike Team — Mon, 26 Oct 2026 21:59:51 +0000

This is week 1 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.

Every side project starts the same way: "I'll put up a waitlist first." Then the waitlist turns into a project of its own. You need a database for the signups, a way to stop bots, a confirmation email, some way to reward people who share it, and a private page where you can see who joined. That's four services before you've written a line of your actual product.

This week we'll build that waitlist with Cursor or Claude Code, and let the agent provision the whole backend through one MCP connection. Every prompt is below, so you can run it yourself.

What we're building

A launch waitlist with referrals:

A landing page with an email form. Each signup gets a personal referral link like /?ref=abc123.
A "you're #N" confirmation email with that link in it.
A live referral leaderboard: every friend who joins with your link moves you up.
Rate limiting, so one IP can't flood the list.
A private admin page behind a login, showing every signup and the top referrers.

Here's how each piece maps to CloudHike, all in one project:

Postgres 16 stores the signups (DATABASE_URL)
Redis 7 runs the leaderboard and the rate limiter (REDIS_URL)
Email sends the confirmation (EMAIL_API_URL, EMAIL_API_KEY, EMAIL_FROM)
Auth protects the admin page (AUTH_URL, AUTH_PUBLISHABLE_KEY, AUTH_SECRET_KEY)

Normally that's a database host, a Redis provider, an email provider and an auth provider: four accounts, four sets of keys, four bills. Here it's one project, one .env and one credit balance, and the agent sets it up.

What you need

A CloudHike account. New accounts get $10 in free credits (eligible accounts, once per inbox, valid for 90 days), no card needed. The Free plan allows 2 projects, which is plenty for this.
Cursor or Claude Code (Codex, VS Code, Windsurf and Gemini CLI work too).
Node.js, for a Next.js app.

Step 1: Connect CloudHike to your agent (once)

In the CloudHike dashboard, open Connect MCP in the sidebar, pick your editor and click Copy with key. That creates your workspace API key and gives you a snippet with the key already filled in. The server is remote (Streamable HTTP), so there's nothing to install.

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. Snippets for the other editors are in the MCP docs.

Treat that key like a password. It lives in your home folder, not in the repo, and you can revoke it from the same page.

Step 2: Scaffold the app

npx create-next-app@latest waitlist
cd waitlist

Open the folder in Cursor, or run claude in it.

Step 3: Let the agent provision the backend

This is the step that usually takes an evening of dashboards. Paste this prompt:

Use the cloudhike MCP tools to set up the backend for this app. It's a launch waitlist with referrals.

Create a CloudHike project called "waitlist" and deploy postgres, redis, email and auth. Wait until they're ready. Put the .env into .env.local, make sure it's git-ignored, and don't show me any secret values. Then read the docs for each service with get_docs so you know how to use them. Don't write app code yet. Just tell me which services are running and which variable names are in .env.local.

Behind the scenes, the agent works through CloudHike's MCP tools:

create_project makes the project (or list_projects finds it if it already exists).
deploy_services deploys Postgres, Redis, Email and Auth, with the same plan and billing checks as the dashboard.
wait_for_services waits until each one reports ready.
get_environment returns the project's .env, which the agent writes into .env.local. It can also ask for format: "names" to list just the variable names with no secrets.
get_docs pulls the Postgres, Redis, Email and Auth pages as Markdown, so the code it writes next follows the real API instead of a guess.

One note: the Email service asks you to accept CloudHike's email acceptable use policy, because it's for transactional mail only. If the agent says Email couldn't be deployed, open the project in the dashboard, tick the box on the Email card, click Deploy, and ask the agent to fetch the .env again.

In editors that show MCP prompts as slash commands, CloudHike also offers a built-in setup_backend prompt that does this step in one go.

Step 4: The signups table

Read https://cloudhike.dev/docs/md/postgres. Using node-postgres, create a signups table with a migration script in this repo: id, email (unique), referral_code (unique, short and random), referred_by (nullable referral code), ip, and created_at. Create the pool once in lib/db.ts, keep it on globalThis so hot reloads reuse it, and use max 5 connections. Run the migration, then use the cloudhike describe_table tool to show me the table.

Why a migration in the repo and not SQL straight through MCP? On the Free plan, CloudHike's database tools are read-only: query_database always runs one statement in a READ ONLY transaction. Writing SQL over MCP (execute_sql) is a Pro-only tool, runs in a single transaction, and is marked destructive, so your editor asks before running it. The docs recommend migrations in your code for schema changes anyway, so they're reviewed and repeatable. And no MCP tool can delete a project or service. Your agent gets enough access to build, and no way to wipe your backend.

Step 5: The signup endpoint, rate limit and leaderboard

Read https://cloudhike.dev/docs/md/redis. Add a POST /api/join route that:

Rate limits by IP with Redis using INCR and EXPIRE: at most 5 joins per IP per 10 minutes, answering 429 when over.

Validates the email and inserts it into signups with a new referral_code. If the email already exists, return the existing referral code instead of an error.

If a valid ?ref code came with the request, saves it as referred_by and runs ZINCRBY on a Redis sorted set called "leaderboard" for that code.

Returns the user's position in the list and their referral link. Use one shared ioredis connection from lib/redis.ts, server code only.

The rate limiter is the same INCR and EXPIRE pattern the Redis docs show, and a sorted set is a natural fit for a leaderboard. One thing worth knowing: CloudHike's Redis runs with noeviction (32 MB on Free), so a full Redis refuses writes instead of silently dropping keys. That's why the rate-limit keys get an expiry and the leaderboard stays small.

Step 6: The confirmation email

Read https://cloudhike.dev/docs/md/email. After a new signup in /api/join, send a confirmation email from server code: POST to EMAIL_API_URL/send with the x-api-key header set to EMAIL_API_KEY, from EMAIL_FROM, with fromName "Waitlist" and replyTo set to my support address from a SUPPORT_EMAIL env variable. Subject "You're on the list (#N)". Include their referral link in both html and text. If the API answers 429, still save the signup and log the error. Don't send anything for duplicate signups.

There's no SMTP to configure and no separate email account. Mail goes out from a CloudHike address straight away, and you can switch to your own domain later by verifying it under Email → Domains in the project. Once it's verified, fetching the .env again picks the domain up. The Logs tab shows who each message went to and whether it was delivered. Message bodies aren't stored.

Keep it transactional: a "you're on the list" confirmation is fine, while a launch-day blast to the whole list would be marketing mail, which the Email service doesn't allow.

Step 7: The admin page

Read https://cloudhike.dev/docs/md/auth. Add an admin area with my CloudHike Auth service: a /login page (email and password sign-in), a server route that stores the returned token in an HTTP-only cookie, and a protected /admin page. On /admin, call get-session from server code and allow access only when the user's email matches an ADMIN_EMAIL env variable. Show the total number of signups, the newest 50, and the top 10 referrers from the Redis leaderboard. Add a sign-out button. Never send AUTH_SECRET_KEY to the browser.

Sign up once with your admin email (a tiny /signup page or the sign-up/email endpoint from the Auth docs works). Because the project already has Postgres, Auth uses its auth schema by default, so your users sit next to your signups and there's still nothing new to host. If you'd rather sign in with GitHub or Google, the Auth card has a shared OAuth app you can switch on.

To check the data without leaving the editor, ask:

Use the cloudhike query_database tool to show the 10 most recent signups and how many came from a referral.

That runs read-only, so it's safe to let the agent explore. You can also open the database explorer in the dashboard to browse the rows.

Step 8: Deploy to Vercel

CloudHike doesn't host apps yet (app hosting is coming soon), so we deploy the Next.js app to Vercel and keep the backend on CloudHike:

Push the repo to GitHub. Check that .env.local is not in the commit.
Import the repo in Vercel.
Add the variables from .env.local under the project's Environment Variables, plus ADMIN_EMAIL and SUPPORT_EMAIL. In the CloudHike dashboard, Environment → Copy as .env gives you the whole file, so you don't have to retype it.
Deploy.

A few production notes from the docs:

Keep the database pool small. DATABASE_URL already goes through a connection pooler (PgBouncer), but each serverless instance opens its own pool, so max: 5 matters.
Free databases sleep. A Free database with no connections for 6 hours is stopped until you click Wake on the card. Pro databases are always on and run in their own container.
Email limits. Free sends 100 emails a day and 3,000 a month. On Pro there's no daily limit, 3,000 a month are included per project, and more cost $0.40 per 1,000. If your launch goes viral, that's the limit you'll hit first.
Auth return sites. If you turn on "Require a verified email" or social sign-in, add your Vercel domain under Sites users can return to on the Auth card.

What CloudHike handled

Look back at what you didn't do: you didn't sign up for a Redis provider, configure SMTP, set up an auth service or copy connection strings between tabs. One MCP connection let the agent:

create the project and deploy four services,
write the .env without showing secrets in chat,
read the real docs for each service before writing code,
inspect the schema and data with read-only tools.

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 unlimited projects. The details are on the plans and billing page.

Your turn

The whole build is the five prompts above, plus the optional query. Run them, tweak them, and see how far your agent gets.

👉 Start free at cloudhike.dev. You get $10 in credits, no card required.

Next week: we put background jobs to work and build an AI app that runs slow work outside the request with retries and webhooks. Follow along so you don't miss it.

If you try this one, tell me in the comments what your agent built, or where it got stuck. I read every comment.

CloudHike vs Supabase: the backend built for AI coding agents

CloudHike Team — Mon, 26 Oct 2026 20:17:51 +0000

Disclosure: I built CloudHike, so read this with that in mind. Supabase details come from Supabase's own docs and pricing pages and were checked on October 26, 2026.

Your coding agent can write a whole app in an afternoon. Then it hits the backend and hands the work back to you: create a database, set up a bucket, find a Redis instance, pick an email provider, wire up a job runner, and paste a dozen secrets into .env.local without committing them.

Supabase and CloudHike both have MCP servers now, so in both cases the agent can help. But they were built for different jobs. Supabase is a mature Postgres platform that added MCP. CloudHike was designed from day one for the agent to set up the whole backend itself, in one prompt, with guardrails that keep it safe.

The short version

Pick CloudHike if you build with Cursor, Claude Code or Codex and want your agent to set up Postgres, S3-compatible storage, Redis, auth, transactional email and background jobs in one go, write your .env for you, and keep it all on one dashboard and one bill.
Pick Supabase if you need realtime, edge functions, social login, self-hosting or a long track record at scale.

Why CloudHike wins for agent-built apps

1. One copy-paste and your agent is connected. Open Connect MCP in the dashboard, click Copy with key, paste the snippet into your editor. The server is remote (Streamable HTTP), so there's nothing to install.

2. The whole backend in one project. Every CloudHike project can deploy:

Postgres 16 → DATABASE_URL
S3-compatible storage (a private bucket with a key scoped to it)
Redis 7 → REDIS_URL
Auth (email and password, users stored in your project's Postgres)
Transactional email with custom domains and delivery logs
Background jobs with retries and webhooks

With Supabase, Redis isn't built in (its own examples use Upstash), and production email means bringing your own SMTP provider. That's more accounts, more keys and more bills for your agent (or you) to wire together. On CloudHike it's one project, one dashboard, one credit balance.

3. The agent writes your .env. The get_environment tool returns the project's env values so the agent can write them straight into your git-ignored env file, without repeating them in chat. No more copying connection strings across five browser tabs.

4. Guardrails that make agent access safe.

query_database always runs in a read-only transaction (one statement, 500 rows, 10 s timeout), on every plan.
Writing SQL (execute_sql) is Pro-only, runs in a single transaction, and is marked destructive, so your editor asks you first.
No MCP tool can delete anything. Deleting projects and services only happens in the dashboard.
Every .env fetch and every SQL write goes to the audit log, and you can revoke the key with one click.

Your agent gets enough power to build, and no way to wipe your data.

5. Pricing you can explain in one line. New accounts get $10 in credits (eligible accounts, once per inbox, valid for 90 days), no card needed. Pro is $10/month with $10 of usage credits included every month and unlimited projects.

From prompt to working backend

Here's the actual flow. Connect the server once.

Claude Code

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

Cursor (~/.cursor/mcp.json)

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

Snippets for Codex, VS Code, Windsurf, Gemini CLI and Claude Desktop are in the MCP docs.

Then open your app's folder and paste this prompt (it's straight from the 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.

What the agent does next:

Reads your code and works out what the app needs, say Postgres, Auth, Storage and Redis.
Calls list_projects or create_project to get a project.
Calls deploy_services for exactly those services, then wait_for_services until they're ready.
Calls get_environment and writes the values to .env.local, making sure the file is git-ignored.
Calls get_docs for each service and writes the connection code, for example a pg pool for DATABASE_URL and a Redis client for REDIS_URL.

You review the diff and run the app. One prompt, no dashboards. If your tool doesn't support MCP, there's also a one-prompt flow that points the agent at https://cloudhike.dev/prompt.md with a token that can only download that project's .env.

Feature comparison

	CloudHike	Supabase
Agent setup over MCP	✅ Remote server, one copy-paste snippet with your key filled in	✅ Remote server with OAuth sign-in
Postgres	✅ Postgres 16 (dedicated container per project on Pro)	✅ Dedicated Postgres per project
S3-compatible storage	✅ Private bucket per project	✅ Storage with CDN
Redis	✅ Built in (Redis 7)	❌ Not built in (examples use Upstash)
Transactional email	✅ Built in, custom domains + delivery logs	⚠️ Auth emails only; bring your own SMTP for production
Background jobs	✅ Jobs service with retries and webhooks	✅ Queues (pgmq) + Cron (pg_cron) + Edge Functions
Auth	✅ Email + password, users in your Postgres	✅ Email, magic link, social OAuth, MFA, SSO
Read-only SQL over MCP	✅ Always, on every plan	Optional (`read_only=true`)
Deletes over MCP	✅ None possible	Some (e.g. `delete_branch`, `pause_project`)
Paid plan	✅ $10/mo, $10 usage credits included, unlimited projects	From $25/month with $10/month compute credits
Realtime	❌	✅
Serverless functions	❌ (app hosting coming soon)	✅ Edge Functions
Open source / self-host	❌ Hosted only	✅

Pricing: one bill instead of four

CloudHike's model is simple: everything (Postgres, storage, Redis, email, jobs) runs from one credit balance, billed by the hour. Sign up and you get $10 in credits, no card. Free covers 2 projects with a 500 MB database, 500 MB of storage, 32 MB of Redis, 100 emails a day and 500 job runs a day.

Pro is $10/month and includes $10 of usage credits every month, unlimited projects, a dedicated Postgres container per project, no idle sleep and up to 30 days of backups. Usage beyond the included credits is metered at the rates on the plans and billing page, and you can set a monthly spend cap. If you hit it, services pause. Nothing is deleted.

The bigger saving is what you don't have to add. On Supabase (pricing), Pro starts at $25/month, and Redis and production email are separate services with their own accounts, keys and bills. On CloudHike they're already in the project your agent just created.

Where Supabase is stronger

To be fair, Supabase is excellent and is the better choice if you need:

Realtime and Edge Functions, which CloudHike doesn't offer today.
Broader auth: social logins, magic links, MFA, SSO.
Open source and self-hosting.
Maturity and ecosystem: compliance options, bigger compute, branching, and a larger MCP toolset (migrations, advisors, type generation).

A quick note

Supabase pricing and MCP tools are from their pages as of October 26, 2026, and both change often. I didn't benchmark performance or latency here.

Try it with your agent

If you build with Cursor, Claude Code or Codex, the fastest way to see the difference is to try it: sign up, copy the MCP snippet, and paste the prompt above into your agent. You start with $10 in free credits, no credit card required.

👉 Get started at cloudhike.dev

CloudHike is new and I'm building it in public. If you try it, tell me in the comments what your agent built, or where it got stuck. I read every comment.

I built CloudHike: a backend your AI coding agent can set up over MCP

CloudHike Team — Mon, 26 Oct 2026 19:16:16 +0000

My AI agent can write a whole Next.js app in an afternoon. Then it stops and hands the hard part back to me: make a Postgres database, set up a storage bucket, find a Redis instance, add auth, pick an email provider, and copy a dozen connection strings into .env.local without committing any of them.

That's five dashboards, five sets of keys and five bills, and the agent can't help with any of it. I kept losing my momentum at exactly that point, so I built CloudHike.

Who's writing this

I run the TubeGuruji YouTube channel, where I make full-stack tutorials. A big part of every tutorial is the "now go sign up for these services" section. Lately most of my building happens with Cursor and Claude Code, and the backend setup has become the slowest part of the whole process. CloudHike is my attempt to fix that for myself, and hopefully for you. I'm building it solo.

What CloudHike is

CloudHike is a backend-as-a-service built for people who code with AI agents. Each project can have:

Postgres (Postgres 16) → DATABASE_URL
S3-compatible storage (a private bucket with a key scoped to that bucket) → S3_ENDPOINT, S3_BUCKET, …
Redis (Redis 7) for caching, queues and rate limits → REDIS_URL
Auth: email and password sign-up and login, with the users stored in your project's Postgres
Transactional email with custom domains and delivery logs
Background jobs with retries and webhooks

It all lives in one dashboard and comes out of one credit balance. Each project is isolated, so one project can never reach another. App hosting is coming soon, but it isn't live yet.

The MCP flow

The part I care about most is the remote MCP server. Once you add it to your editor, your agent can do the backend setup itself.

Setting	Value
Server URL	`https://cloudhike.dev/api/mcp`
Transport	Streamable HTTP (remote, nothing to install)
Auth	`Authorization: Bearer <workspace API key>`

You get the workspace API key from Connect MCP in the dashboard sidebar. Click Copy with key and the snippet comes with your key already filled in.

Claude Code

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

Then 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. The MCP docs also have snippets for Codex, VS Code, Windsurf, Gemini CLI and Claude Desktop.

What the agent can actually do

These are the tools the server exposes:

list_projects, create_project, get_project: find or create a project
deploy_services: deploy postgres, auth, storage, redis, jobs or email, with the same plan and billing checks as the dashboard
wait_for_services: wait until the services are ready before writing any code against them
get_environment: get the project's .env so the agent can write it to your git-ignored env file
list_tables, describe_table, query_database: look at your schema and run read-only SQL
list_storage_files: browse the bucket
get_docs: read any CloudHike docs page as Markdown

There are a few guardrails I cared about. query_database always runs in a read-only transaction. Writing SQL (execute_sql) is Pro-only, runs in a single transaction, and is marked destructive so your editor asks you first. Nothing can be deleted through MCP. Deleting projects and services only happens in the dashboard. Every .env fetch and every SQL write goes to the audit log, and you can revoke the key with one click.

An example

With the server connected, open your app's folder and paste this prompt (it's from the 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.

Here's what the agent then does:

Reads your code and works out what the app needs, say Postgres, Auth and Storage.
Calls list_projects or create_project to get a project.
Calls deploy_services for those three, then wait_for_services until they're ready.
Calls get_environment and writes the values to .env.local, making sure the file is git-ignored.
Calls get_docs for the matching pages and writes the connection code, for example a pg pool for DATABASE_URL.

You review the diff and run the app. You still own the code, so read what it changed. The point is that you no longer need five browser tabs.

If your tool doesn't support MCP, there's also a one-prompt flow. You paste a prompt that points the agent at https://cloudhike.dev/prompt.md, together with a token that can only download that project's .env.

Pricing

I wanted this to be simple:

Free: every new account gets $10 in credits at signup, no credit card required. The credits last 90 days, and Free includes 2 projects.
Pro: $10/month, which includes $10 in usage credits every month and unlimited projects, plus a dedicated Postgres container per project, live-resizable Redis and no database sleep.

Services are billed by the hour from credits. You can set a monthly spend cap in Settings, and if you run out of credits, nothing gets deleted. The full meter rates are on the Plans and billing page.

What's next, and what I need from you

App hosting (deploy from GitHub, Docker or a template, with an HTTPS address) is the next big piece. CloudHike is new and I'm building it in public, so I'd really like your feedback:

Does the MCP flow work in your editor? Where does it break?
Which tool is missing that your agent keeps asking for?
Is the pricing clear?

Try it at cloudhike.dev and tell me in the comments what you built, or what got in your way. I read every comment.