Void Platform Walkthrough: Install a Shared Cloudflare Deploy Platform

Setting up shared deployment infrastructure is easy to postpone — until three developers are each shipping to their own Cloudflare account and nobody can roll back the same release. A Void Platform walkthrough fixes that by turning a vague "we should self-host" ambition into an ordered checklist. Below you'll find a practical Void Platform walkthrough that covers what the platform actually is, which credentials to gather first, how the core install is sequenced, and which optional services most teams bolt on later.

Most confusion around this product comes from a single fork in the road: deploying for yourself versus deploying for a team. If you're shipping your own app, you deploy directly to Cloudflare and never touch a platform install. If you're the administrator standing up shared infrastructure, the platform becomes the thing you install, maintain, and hand a URL to. Everything here assumes you're in that second camp.

What a Void Platform Actually Does

A Void platform lets a team deploy applications into a shared Cloudflare account. That one sentence carries most of the value: instead of every developer wiring up their own account, tokens, and gateway, the administrator installs and maintains one platform. Developers then point the Void CLI at its URL, sign in through an enabled login method, and deploy.

The platform isn't a separate hosting product. Both deployment targets use the same application APIs, so an app doesn't need to be rewritten to move from a direct Cloudflare deploy onto a team platform. What the platform adds is shared access plus retained deployment history — two things that matter enormously once more than one person ships code.

The split matters because it defines your job. During installation you are the administrator, not a developer. Your success metric isn't "my app is live" — it's "a teammate I've never met can authenticate and deploy without messaging me."

Prerequisites and Credentials to Line Up First

The fastest way to stall a Void Platform walkthrough is to discover halfway through that you're missing a plan tier or an account permission. The official Void self-hosted platform installation guide splits this into prerequisites and credentials for good reason: they're separate decisions with separate owners.

Work through the list below before you touch the installer. Each row is something you should be able to answer with a name, not a shrug.

Two of these are commonly underestimated. The first is the account choice: migrating a platform later is far more painful than choosing a dedicated account up front. The second is the login method — it is not a post-install afterthought, it is the gate every developer passes through.

The Void Platform Walkthrough, Step by Step

The sequence below follows the installation guides in order, from prerequisites through credentials and into the core install. Treat each step as a gate: don't advance until the "done" column is genuinely true.

Steps 1–3: Scope, prerequisites, credentials

Start by writing down the answer to a blunt question: is this platform for one person or for a team? If it's one person, stop — deploy directly to Cloudflare instead. If it's a team, the answer commits you to Workers for Platforms and the documented infrastructure, so budget for that before scheduling any install window.

Steps 4–5: Install the core and switch on email

The core installation includes managed Sandboxes and an email gateway. Email doesn't come online by itself; it's enabled when you configure a shared mail domain and zone. If transactional email from deployed apps is part of your plan, treat this as a required step rather than a nice-to-have, and verify it with a real send before you invite developers.

Steps 6–8: Authentication, first deploy, and the roadmap

Enable a login method, hand the platform URL to one pilot developer, and have them connect the Void CLI and deploy something small. That single test surfaces more configuration problems than any checklist. Once it passes, write down the optional services you're deferring — GitHub builds, build Containers, custom project domains — so nobody assumes they shipped with the core.

Direct Cloudflare vs. the Core Self-Hosted Platform

This is the comparison table worth bookmarking, because it answers "what am I actually gaining?" Both targets share the same application APIs; the differences are about shared access, retention, and where requests flow.

Read the last two rows carefully. Sandboxes on the platform only need Workers Paid on the platform account, whereas direct deployment also expects Docker in your local workflow. And the dashboard plus managed GitHub builds are not part of a standard installation on either side — they're additions you opt into.

For a solo project, the left column is less work for the same application APIs. For a team, the right column's retained logs and retained deployments are what make debugging a shared release possible at all.

Optional Services and Configuration Traps

Once your Void Platform walkthrough clears the core install, the remaining work is elective — but each option has a configuration consequence. Plan them deliberately rather than discovering them when a developer asks why their branch preview is missing.

Two habits prevent most of these. First, keep a short configuration record: which login methods are enabled, which mail domain is shared, and which optional services are live. Second, when Cloudflare Access protects the API and you're running a source-built platform with GitHub services, follow the isolated webhook ingress setup rather than loosening Access — the fix belongs in the ingress path, not in your security posture.

Finally, remember that a team platform depends on its configuration. Features documented for one installation may be absent from yours simply because they weren't enabled, so verify against your own setup instead of assuming a default.

FAQ

Do I need a Void Platform walkthrough if I'm only deploying my own app? No. If you're deploying an app for yourself, deploy directly to Cloudflare. Installing a platform is only worth the overhead when a team needs shared access and retained deployment history.

Is the user dashboard included in a standard installation? No. The user dashboard, managed GitHub builds and webhooks, build Containers, and custom project domains are not part of the core installation. Plan for them as separate additions.

What does the platform account need in order to run Sandboxes? Workers Paid on the platform account. Direct Cloudflare deployment has a slightly different requirement and also expects Docker for Sandboxes.

Can we add GitHub builds after the core install? Yes — it's an optional service. If you're on a source-built platform and Cloudflare Access protects the API, set up isolated webhook ingress so builds and webhooks keep working without weakening access control.