How to host an MCP server — and turn it into a product

2026 is the year everyone started building MCP servers. The tutorials all end the same place: a server speaking stdio to a client on the same laptop. Which is fine — until you want your tools available from every machine you use, shared with a team, backed by real data, or sold to customers.

Then you need a hosted MCP server, and the guides go quiet. Here’s the whole pattern.

What a hosted MCP server actually needs

• An HTTPS endpoint speaking a remote transport — streamable HTTP or SSE, not stdio.
• Authentication: it’s on the public internet now; anonymous clients can’t be allowed to call your tools.
• Per-client credentials — so you know who’s calling and can cut one client off without cutting off everyone.
• A place for state that survives restarts.
• Ideally, a human-facing page too — docs, a dashboard, a way to sign up.

That list is why most MCP servers stay on laptops: it’s a weekend of infrastructure for a tool you wrote in an hour.

The pattern on Alora, end to end

1. The server. Write your MCP server with the official SDK, but serve it over streamable HTTP on the port the platform gives you — a normal web app whose /mcp route speaks MCP:

// server.js — express + @modelcontextprotocol/sdk
app.post('/mcp', (req, res) => transport.handleRequest(req, res));
app.get('/', (req, res) => res.send(dashboardHtml));   // humans land here
app.listen(process.env.PORT);

2. The deploy. alora deploy — or tell your agent to do it. You get https://mytools.alora.page with TLS, and anything you write under the data directory survives restarts (SQLite is perfect here).

3. A token per customer. This is the part that makes it a product instead of a demo:

alora tokens create mytools --name ana
→ ptok_9f2c…   (give this to Ana, and only Ana)

Ana connects from her own machine:

claude mcp add --transport http mytools https://mytools.alora.page/mcp \
  --header "Authorization: Bearer ptok_9f2c…"

4. Knowing who’s calling. Alora’s proxy checks the token before the request ever reaches your code, then hands you the caller’s identity as trusted headers:

req.headers['x-alora-user-name']   // "ana" — the token’s name
req.headers['x-alora-user-role']   // "service"

Your server reads one header and knows which customer this is — for per-customer data, limits, or billing. No auth code, no key table, no middleware. When Ana’s trial ends: alora tokens revoke, and her next call bounces at the proxy.

5. The human surface. The same URL, opened in a browser, is a normal private app: visitors get a login page, you invite people by email, and your dashboard route serves them with their identity in the same headers. One deploy ships the product for agents and the page for people.

The economics are almost unfair

An MCP server is the sleepiest workload imaginable — it works in bursts, when some agent somewhere needs a tool. On Alora it sleeps for $0 and wakes on the next request; a tools server your five customers hit a few times a day runs well under a dollar a month. You charge them; the infrastructure charges you cents.

The honest boundaries

• Tokens are created by you (or your agent) — invite-style onboarding, perfect for teams, clients and early customers. Self-serve signup for strangers means building your own key-issuing layer on top.
• A sleeping server adds a beat of cold-start to the first call of a burst. For always-hot tools, alora scale --always-on is ~$7/month.
• Your MCP client needs remote-transport support (Claude Code: --transport http or sse — both pass through Alora’s proxy, WebSockets included).

The full pattern is in the agent docs, which means the fastest way to try it is also the laziest: tell your agent “build me an MCP server for X and host it on Alora” — and it takes it from there.