Install the Cloudflare edition

The Cloudflare edition is the same panel, built for WebAssembly and run by six Cloudflare Workers with a D1 database, instead of a binary on your own Linux server. One command, mistgate edge deploy, creates everything on your Cloudflare account. The nodes are still your servers, added from the admin as usual. This page takes you from a Cloudflare account to the owner account in the admin. The examples use panel.example.com.

Requirements#

Create the API token#

The command talks to the Cloudflare API with a token you create. In the Cloudflare dashboard open My Profile → API Tokens → Create Token → Create Custom Token and give it these permissions:

Under Account Resources pick your account, and under Zone Resources the one zone of the host.

Important: this list is worked out from the API calls the command makes. It is not confirmed on a real account; the exact minimum is known only after the first real deploy. If the command stops with a permission error, the message says at which call. The most likely gap is the custom domain, which may also need Zone: DNS: Edit: add the permission and run the command again with --resume.

Give the token to the command only through the environment variable CLOUDFLARE_API_TOKEN. There is no flag for it, so it stays out of the process list, and the command never writes it to the key file or to Cloudflare; it is replaced by [REDACTED] in error messages. In bash the line below also keeps it out of the history; in PowerShell use $env:CLOUDFLARE_API_TOKEN = "...":

read -rs CLOUDFLARE_API_TOKEN && export CLOUDFLARE_API_TOKEN

Only the command on your computer uses the token; the deployed panel never receives it. Delete the token in the dashboard when you are done, and create a new one for the next deploy.

Deploy#

Look at the plan first. --dry-run only reads from Cloudflare (the token, the zone, existing scripts and databases), checks the bundle and prints what a real run would do. It creates no file and nothing on Cloudflare:

mistgate edge deploy --host panel.example.com --dry-run

Then run it for real:

mistgate edge deploy --host panel.example.com

The panel is six Workers. Only the first has the domain; the others have no address of their own and are reached through it:

• <name>, the front Worker: a small router with no WebAssembly. It sends each request to one of the others by its path, and owns the Durable Objects that the nodes' agents connect to.
• <name>-public: subscriptions, the user page and the decoy site.
• <name>-link: the panel's side of the agent link.
• <name>-admin: the admin and its API. It is the only one that creates the panel on an empty database.
• <name>-jobs: the job that the cron trigger starts every minute.
• <name>-provision: SSH installs of nodes.

All six use the one D1 database.

A run does these steps, in this order, and stops at the first failure:

1. Downloads the bundle and verifies its signature.
2. Checks the token and finds the account and the zone of the host.
3. Refuses to go on if a Worker script or a D1 database with that name already exists while the key file is missing: it never adopts or replaces what it cannot open with its own keys.
4. Writes the key file (see below), before it creates anything.
5. Creates the D1 database.
6. Uploads the six scripts in this order: link, provision, public, admin, jobs, and the front Worker last, so that a script is there before the one that binds it. The very first time the front Worker goes up before all of them, with no bindings to the others, because the link Worker binds its Durable Objects; it goes up again at the end with them. The admin's static files go up with public and admin. The secrets go up with each script: MASTER_KEY in the five scripts that run the panel, and the secret admin path, the subscription path and the hash of the setup token in admin only. A script whose content is the same as at the last run is not uploaded again.
7. Turns off the workers.dev name and the preview URLs of each script right after its upload, sets a cron trigger that runs every minute on the jobs script, and attaches panel.example.com to the front Worker as a custom domain. Cloudflare creates the DNS record and the certificate.
8. Waits up to five minutes for the decoy page at https://panel.example.com/ to answer, then prints the links.

Workers Logs are switched off on all six scripts.

The key file#

The command writes mistgate-edge-<name>.json in the current directory (mistgate-edge-mistgate-edge.json with the default name) and prints its full path. It holds everything that cannot be read back from Cloudflare: the master key of the panel, the secret admin path and subscription path, the setup token, and the ids of your account, zone and database. After an update it also holds the version each script had before it, for a rollback.

On Linux and macOS the file is created with mode 0600. On Windows the mode is not enforced: the file inherits the folder's permissions, so keep it in a private folder (the command warns about this). --resume needs the file in the folder you run the command from, and setup-link takes its path.

If a run stops half way (a network error, Ctrl+C, a Cloudflare error), nothing is rolled back and the key file stays. Fix the cause and run the same command again with --resume: it reads the key file and the bundle version recorded in it, and continues with the same keys and the same setup token; scripts that were uploaded already are not uploaded again. Without --resume, a run that finds the key file counts as an update (see below).

After the deploy#

The command prints where the key file is, the admin address (https://panel.example.com/ plus a secret path of 24 random characters) and the one-time setup link:

Admin URL: https://panel.example.com/<secret path>/
Setup link (one-time; the token is valid for 30 minutes from the panel's first start): https://panel.example.com/<secret path>/setup#<token>

The admin address is secret on purpose, as in the secret path mode of a VPS panel: anyone else who opens the host sees only the decoy site. Keep the address; it is also in the key file.

Open the setup link in a browser and create the owner account, as in Install the panel (step 8, "Sign in for the first time"). The panel starts for the first time at the first request or the first cron tick, in practice within a minute of the upload, and the token is valid for 30 minutes from that moment. The part after # never reaches a server.

If the link has expired, or you closed the page before the account existed:

• mistgate edge setup-link --file mistgate-edge-mistgate-edge.json prints the stored link again. It carries the same token, so it helps with a lost link but not with an expired one.
• For a new token, run mistgate edge deploy --host panel.example.com again without --resume: it uploads the same bundle again and makes a new setup token. This works only while no admin exists; the link of a panel that has an owner does nothing.

If the last line of the output says that the host did not answer HTTP 200 yet, Cloudflare is probably still issuing the certificate of the custom domain. The deploy itself is finished: open the link in a few minutes.

Add nodes#

Add nodes in Nodes → Add node as on a VPS panel; see Add a node. Installing over SSH works on this edition too, with these differences (the details are in Install a node over SSH):

• The panel connects to the new server from Cloudflare's network, so SSH on the server must accept connections from the internet for the time of the install, not only from your own address.
• The panel refuses addresses that belong to Cloudflare or sit behind its proxy, private networks and servers reachable only through a VPN. The wizard says "The panel's network refused this address, or the server cannot be reached from it". Use the server's own public address or a name that is DNS-only.
• Use the manual install command whenever SSH does not work this way, or the server accepts only SSH keys. The wizard offers it next to the error. The agent connects out to the panel, so it works from any network that can reach panel.example.com.

Not available in this edition yet#

The admin shows "Not available in the Cloudflare edition yet" in the places below, and a call that would start such work is refused with the same words. Everything else works as on a VPS panel: nodes, profiles, users, subscriptions and the user page, the node doctor and the SSH install.

Limits of this edition that matter for devices:

• Each device has its own keys on each node, and the panel remembers what it sent to a node in one D1 row, which D1 caps at 2 MB. That is about 38,000 credentials per node, roughly 7,500 people with two link protocols each at 2.5 devices on average (about 19,000 people before devices had keys of their own). The panel writes a warning to its log, once per node, when the row passes 1.5 MB.
• The hourly cleanup makes one more D1 call (it removes old deleted devices).

Registering a WARP account from the panel is not available either and fails with "WARP registration is unavailable in this edition"; the admin does not mark it yet.

Update#

Download a newer mistgate (or pass --version vX.Y.Z) and run the command again with the same --host and --name, from the folder with the key file, without --resume:

mistgate edge deploy --host panel.example.com

It reads the key file, so the keys, the database and the secret paths stay. It uploads the scripts whose content changed (a release that leaves the front Worker alone does not restart the agents' connections), applies the new Durable Object migrations and makes a new setup token, which you can ignore (it is why admin is uploaded every time). A bundle that is older than what is deployed is refused before anything is uploaded. While the front Worker is replaced, connected agents reconnect on their own and an SSH install in progress is retried (its third interruption fails it). The key file is rewritten with the new bundle version; the master key stays, so your earlier backup of the file still opens everything. Read the release notes first: there is no backup of the database to go back to, and a rollback does not touch it.

Roll back#

If an update misbehaves, run this from the folder with the key file:

mistgate edge deploy --host panel.example.com --rollback

Before an update uploads anything, the command notes in the key file the active version of each of the six scripts and its cron schedule. --rollback puts them back through Cloudflare's deployments, the front Worker first and then the others in the reverse order of the upload, and restores the schedules. It uses the same token, takes no bundle and uploads nothing; with --dry-run it only lists what it would restore. A script that the last update created has no earlier version and stays as it is.

• The D1 database is not rolled back. A release is meant to change its schema only by adding to it, so the version before the update still runs on it.
• It goes back one update: the key file keeps the versions before the last new bundle. After the first deploy there is nothing to go back to.
• The next mistgate edge deploy uploads all six scripts again.

Moving between a VPS panel and the edge#

Not supported yet. There is no way to carry users, nodes and subscription links from a VPS panel to the edge or back: a backup archive of a VPS panel cannot be restored on the edge, and nodes cannot be told to follow a new panel address. Choose the edition for a new fleet, or plan to re-create the users and enrol every node again. A move in both directions, with subscription links that keep working, is planned but not built.

When the command stops#

Next#

Add a node, then First users. Every other page of the guide applies, except for the features listed above. How the parts fit together: Architecture.