Domains and resources
Connect your domain and see which Cloudflare resources the platform uses.
On this pageAdd a domain to the platform · Use other domain options · Review the Cloudflare footprint
Adding a domain
Requires: login or token
These commands need Cloudflare credentials for the installation.
This step previews and applies the domain once it is ready.
void platform domain set example.app --plan
void platform domain set example.appExample output: A preview, then the domain set.
The command picks your platform, or offers a picker. It finds or creates the zone, sets up DNS and routing, and verifies HTTPS. Then it publishes the new app URLs. Set the management token as described in installation setup when creating DNS or a zone. Grant the existing runtime token Cache Purge: Purge on the new zone; the platform checks that permission through the running platform without asking you to paste its token again.
If nameservers, certificates or project Zero Trust are pending, follow the printed guidance and rerun the command. The SDK preserves each project's public or protected setting before making the new URLs available. Your workers.dev app URLs continue working during and after setup. Projects, deployments, secrets, and the platform API URL stay the same, so developers do not reconnect and configured login callbacks do not change. DNS and configuration changes may take time to propagate.
Use --installation <id> to select an installation explicitly, --zone example.com for an app domain such as apps.example.com, or --dedicated-zone for catch-all routing on a dedicated zone. Nested domains still need the wildcard certificate described below. This command adds the first domain; replacing an existing application domain is not currently supported. It uses the installed runtime and does not require --runtime or an app redeploy.
Choose an application domain whose wildcard leaves existing Worker Custom Domains reachable. Existing more-specific routes covering all requests can preserve those hostnames. If the platform reports a conflict, choose another application domain; for a new installation, you can start with void platform install --workers-dev and add a suitable domain later.
Browser login sessions are tied to each origin. Apps with their own OAuth providers may need to register new callback URLs. The platform's built-in auth uses the request origin automatically unless the app overrides that configuration.
Apps on one application domain can set cookies that the other apps there receive. With a nested domain such as apps.example.com, apps can also set cookies for example.com and its other subdomains. Apps on workers.dev testing URLs can set cookies that every Worker on your account's workers.dev subdomain receives. If people outside your team can deploy, use a domain that serves only SDK apps. A platform that serves thousands of independent developers can also apply to list its application domain on the Public Suffix List.
What changes in testing mode?
In testing mode, each app gets a workers.dev URL. These URLs keep working after you add a domain. New apps then use the domain.
Testing URLs support WebSockets, SSE and shared ISR storage. They skip the extra edge response cache. Their forwarding Workers remain for manual cleanup after uninstall. Platform disablement and project suspension still block their traffic.
Other domain options
Custom API hostname
Pass --control-plane-domain platform.example.net during installation. The hostname must belong to a zone the selected account and management token can manage. Omitting it keeps the API on workers.dev.
Using a nested application domain
Use apps.example.com within an existing company zone
An app at my-app.apps.example.com needs a certificate for *.apps.example.com. Universal SSL for example.com covers only first-level hostnames. Configure an active wildcard certificate with Advanced Certificate Manager, a paid add-on, or use an existing custom wildcard certificate before installation:
void platform install --application-domain apps.example.com --zone example.com --planExample output: A preview of the planned changes. Nothing is applied yet.
The management token needs SSL and Certificates: Read (or Edit) on that zone for the certificate check. The SDK does not order certificates or enable paid products automatically. Leave --dedicated-zone off: that flag is only for installations whose application domain is the entire zone and adds catch-all routes for otherwise unmatched traffic.
Optional dashboard
The core installation includes the API's /admin/ pages. You can deploy the optional user dashboard separately. Set its HTTPS origin during installation with --dashboard-url https://dash.example.com.
This step previews and applies the dashboard origin on an existing installation.
void platform repair <installation-id> --dashboard-url https://dash.example.com --plan
void platform repair <installation-id> --dashboard-url https://dash.example.com --yesExample output: A preview, then the repair applied.
The origin must have no credentials, path, query or fragment. The SDK saves it for login callbacks and keeps it across upgrades and repairs. The command does not create a dashboard Worker or DNS records. Follow the source app’s standalone dashboard preparation to deploy your own copy with an unused Worker name, your dashboard hostname, and the installed API Worker’s service binding. Set its API_URL to the public API origin, DASHBOARD_URL to the dashboard origin, and SITE_DOMAIN to the installation’s application domain. Omit the option to keep the saved origin. The dashboard offers sign-in, linked logins and sign-out. Use the CLI for project and team management.
If Access protects the platform, its application must cover this dashboard origin too. Configure the origin when installing protection. To change it on an already protected platform, deliberately remove protection through authentication configuration, apply the origin, then enable protection again. Choose a separate admission rule first if signup depends on the Access gate. Maintenance stops if the configured origin is outside the active coverage.
Cloudflare footprint
New platform resources use deterministic void-<installation-name>-<role> names where Cloudflare allows them, such as void-team-api. Choose an unused installation name in the account; the platform stops on an unowned name conflict instead of replacing that resource. Existing installations keep their recorded names, including older names with suffixes.
| Resource | Count | Purpose |
|---|---|---|
| Workers | 5, plus one per app using workers.dev | API/control plane, proxy, tail ingestion, dispatch, email gateway, and test-origin forwarders |
| KV namespaces | 3 | Routing, ISR cache, and static asset storage |
| R2 buckets | 1 | Static and deployment assets |
| Queues | 3 | Usage events, cron firing, and deployments |
| Workers for Platforms dispatch namespaces | 1 | User application Workers |
| Hyperdrive configurations | 1 | External platform PostgreSQL |
| AI Gateways | 1 | Installation-isolated AI routing and metering |
| Proxied wildcard DNS records | 0 or 1 | Created only when an application domain is configured |
| Zones | 0 or 1 | Created only when the requested application zone is absent |
The API Worker uses four Durable Object classes for usage, cron scheduling, error monitoring, and concurrency. Worker bindings create the request and log datasets in Analytics Engine, which must be enabled for the account. The core installation doesn't create Container applications, a GitHub App, a dashboard Worker, or build Workers.
