feat(deploy): proof-of-concept Maple Cloud self-host on celld

[xesrevinu]

Proof of concept — not a production proposal

This is an experiment in running Maple Cloud (the Workers API + web UI + electric-sync + alerting) on celld so a VPS can sit behind something like Cloudflare Tunnel without putting the app on Cloudflare Workers, and without Wrangler / Miniflare / Alchemy.

It is not:

• a replacement for hosted Maple (alchemy deploy)
• a replacement for local-mode maple start (telemetry-only single binary)
• a request to take celld as the official self-host path yet

The goal is to keep one Worker source (wrangler.celld.jsonc is a stripped subset of the existing Wrangler config) instead of rewriting the API as a second Node/Express server.

Postgres

celld v0.4.1 implements outbound TCP through cloudflare:sockets. The Worker dials Postgres the same way Cloud does (postgres.js cf build, request-scoped pool). Hosted Workers still prefer the MAPLE_DB Hyperdrive binding; celld has no Hyperdrive, so it uses MAPLE_PG_URL.

There is no WebSocket sidecar. ClickHouse is already HTTP.

What this adds

• Dev: bash scripts/celld-dev.sh — three celld dev processes (api / electric-sync / alerting) against docker Postgres + ClickHouse + Electric.
• Prod packaging: deploy/celld-self-host/ — Compose one-command stack, Caddy same-origin, Kustomize. Default docker compose --env-file .env up --build → http://127.0.0.1:8080. BYO Postgres/S3: copy the folder and delete those services.
• Same-origin SPA: empty VITE_* URLs; Electric ShapeStream requires an absolute URL, so production resolves location.origin.
• AES-GCM via Web Crypto: celld's node:crypto HMAC works; createCipheriv("aes-256-gcm") does not. Stored {ciphertext,iv,tag} layout is unchanged.

Other celld limits (v0.4.1)

wrangler keys hyperdrive / ai / ratelimits / send_email / dev / workers_dev abort deploy. Queues omitted (celld refuses a queue consumer on a Worker that also exports fetch). Cron / DO / R2 are Partial. node:net is still unimplemented; sockets go through cloudflare:sockets and die with the event.

How to try it

cd deploy/celld-self-host
cp env.example .env
# set MAPLE_ROOT_PASSWORD and the two MAPLE_INGEST_KEY_* secrets
docker compose --env-file .env up --build

Sign in at http://127.0.0.1:8080 with MAPLE_ROOT_PASSWORD (docs examples use change-me). Stop any local celld-dev stack first so 8080/4317 stay the default ports.

First boot still needs Drizzle migrate + ClickHouse schema + Electric publication (same heal as dev:celld).

Relevant issues

• Self-hosting the full stack outside Cloudflare — working Miniflare-based deployment, offering fixes upstream #352
• feat(self-host): full Docker Compose self-hosting via a Miniflare runtime #450

Generated by Grok 4.6

[xesrevinu]

Hey—I've just started trying maple recently, it's very interesting. Thank you for your continuous dedication; the daily experience is really great, and I will keep an eye on it.

The one place I got stuck is running it on my own VPS. What I actually want is to keep the app on the machine and expose it through Cloudflare Tunnel, not to run it as Cloudflare Workers. Tunnel vs Workers is a different shape of “on Cloudflare,” and the current Cloud path is pretty tightly bound to the latter.

So this draft is just a spike: same Worker source, celld as the runtime, origin sits on the VPS and can go out via a tunnel. The awkward bit is Postgres — celld doesn’t have Hyperdrive or working cloudflare:sockets / TCP yet, which is why there’s a WebSocket sidecar. If celld can dial PG directly later, that part should disappear.

Totally a POC, not a “please merge this.” Figured I’d share the experiment in case the direction is interesting.

[xesrevinu]

One small note on product shape, since this is the Cloud stack rather than maple start.

I know you’re building a business around hosted Maple, and I don’t want this to read as “here’s how to skip that.” Local-mode already covers self-host telemetry; this spike is just our VPS + tunnel case. If a recipe like this would get in the way of what you’re commercializing, totally fine to leave it as a draft or a fork — we’ll follow your lead ❤️.

[Makisuo]

Hey, I think this is quite cool and would love to make Maple easier for self hosting! But don't want to commit something right now since I expect it to still change a lot, especially on the architecture side, which would make development quite a pain if I try to maintain parity for self hosters right now!

But in general love the initiative here and it's deff something im really intersted in supporting a long the oad.

[xesrevinu]

😃 I completely understand that you are in a fast development phase, and this approach is just an interesting attempt. I believe that in the future, Achemy can provide a more convenient deployment method. I am also trying to integrate Maple into the product and will keep following Maple's excellent work.