Self-hosting an App

For an internal app that should never touch the public internet, export it from cdbx and run it entirely inside your own network. This uses the same export you already have (ZIP download or GitHub sync) — there's no separate "private deploy" feature to turn on.

This is for apps with a real backend/container. It doesn't apply to an app still on the instant browser runtime.

What you get

Every server-backed app's export now includes two extra files at the root, alongside your code:

• Dockerfile — builds and runs your app with no cdbx involvement.
• RUN.md — the exact commands to build, run, and configure it, generated from your app's own dev/build/start settings.

If you already have your own Dockerfile in the app, cdbx leaves it alone — it only adds one if you don't have one.

Export

Use either export method — both include the Dockerfile:

• Download ZIP — Settings → Copy & Export → Download ZIP
• Sync to GitHub — Settings → Copy & Export → Sync to GitHub

Build and run it standalone

docker build -t myapp .
docker run -p 3000:3000 --env-file .env myapp

The exact port is whatever your app runs on — check the EXPOSE line in the generated Dockerfile, or RUN.md.

Environment variables

An export never includes your environment variable values — only cdbx's encrypted database has those, and they don't leave it. RUN.md lists the variable names your app uses; before you leave cdbx, copy the actual values from Settings → Environment Variables and put them in a .env file next to the Dockerfile.

Putting it behind your own zero-trust network

Once the container runs, the goal for a fully private deploy is: no public URL, no public DNS record — only people on your company's network (or VPN) can reach it.

1. Run the container inside your VPC or on-prem network. Don't map its port to a public-facing interface.
2. Point your zero-trust client at the container's internal address — a Zscaler ZPA App Connector, Cloudflare Tunnel, Tailscale, or your own team's equivalent all work the same way here: they forward traffic from your zero-trust network to one internal host:port, with nothing exposed to the public internet.
3. Your team accesses the app only through that zero-trust client. There's no cdbx URL involved at any point after export.

This is exactly how a company would run an internal cdbx-built tool restricted to their own network and their own @company.com accounts — combine this with domain-gated login inside the app itself for a second, independent layer of restriction.

What this isn't

• Not a managed hosting product — once exported, cdbx has no visibility into or control over the running container. Updates require re-exporting and rebuilding.
• Not automatic — you (or your ops team) own the container, the network placement, and the zero-trust connector.