Connect
Select a repository and branch
Install the GitHub connection, choose the code to run, then add environment values and runtime secrets.
Deployment and operation
From repository to regional microVMs, then through Cloudflare to the nearest healthy capacity.
How Velcio runs an application
Deployment sequence
Build
Produce a versioned image
Velcio detects a buildpack when no Dockerfile exists. Repositories with a Dockerfile use those build instructions.
Place
Start regional microVMs
Choose one or more regions and set the replica count in each. Every positive count is active capacity.
Operate
Maintain the regional counts
Velcio checks health, removes failed instances from routing and restores the configured count in each region.
How requests are routed
Web regions are peers. Selection happens at the edge, on a host, and without session stickiness.
Request
Cloudflare receives traffic for the public hostname.
Region
The edge prefers the nearest region with healthy configured capacity.
Origin
Within that region, a worker host is weighted by its ready replica count.
Replica
Caddy selects a ready instance on the chosen host.
Retry
An eligible bodyless request can try one alternate origin after an early failure.
Normal capacity stays in your configured regions. Where regional recovery is enabled, Standard and Pro may temporarily run and serve traffic from another region. Your app shows its recovery destination and readiness.
How unhealthy replicas are handled
Detect
Health checks fail
Drain
New traffic stops
Replace
Workload returns
Readmit
Success is sustained
Regional capacity
All configured regions are active. If one has no healthy origin, Cloudflare uses another configured healthy region.
Purchased counts stay unchanged. During a regional outage, eligible apps can temporarily use a prepared copy elsewhere, then return after the affected region is stable and its replicas are healthy.
Prepared before a region fails
Velcio is built for replaceable, stateless web apps. Where enabled, Standard and Pro prepare an image copy in the nearest eligible region to each replica's source region. Regions are ranked by geographic distance, not visitor location or measured network latency; unavailable or incompatible hosts are skipped. No app process is running in that copy: it uses storage, not an active VM's CPU and RAM. Pro also needs reservable scheduler capacity for protection to be ready.
After a sustained regional failure, Velcio starts the prepared copy with the current configuration and secrets, checks HTTP readiness, then admits it to routing. The cached filesystem avoids fetching and converting the image during recovery. Startup still depends on your app and its external services.
Once the source region has remained stable and its replicas are healthy, traffic returns and the temporary instance is removed. The recovery copy is prepared again. Stop pauses recovery and removes prepared copies; restarting prepares them again.
Standard: best-effort activation after Pro, using remaining capacity. A prepared copy does not mean capacity is available to run it.
Pro: priority activation with capacity reserved once protection is ready. Preparation and reservation gaps are visible in the app. Reserved capacity does not guarantee availability if the recovery region or shared infrastructure also fails.
No extra recovery replica charge: preparation and temporary recovery do not increase purchased counts. Normal hosting charges continue. This is not paid active-active hosting, a backup service, or a fixed recovery-time SLA.
Recovery can move traffic and runtime secrets outside your chosen regions. External databases, object storage and allowlists must work from the recovery region. Database outages, local files, in-memory sessions and open connections are not recovered. Check the app's recovery status before relying on this feature.
Application requirements
Your app
Repository, deploy branch, runtime values, a process bound to PORT, and a health endpoint.
Velcio
Build, regional microVMs, secrets injection, TLS, Cloudflare routing and automatic recovery.
Persistent disks and apps that depend on local state are not supported. Keep durable data in external databases or object storage, and shared sessions outside the app process. Replacements start fresh.