How Velcio runs your app

Isolation first. Then a consistent build. Then live review before you accept.

Each delivery gets its own microVM

Untrusted builds and live review sessions run in dedicated Firecracker microVMs. Projects do not share a host process space with each other. That is how we can accept real deliveries without dropping them on a noisy shared host next to strangers.

Compute on Azure VMs we operate

Worker hosts run on Azure virtual machines with nested virtualisation so Firecracker can run. You get a managed fleet for review and optional hosting, not an anonymous shared PaaS slot you cannot reason about.

Buildpacks by default. Dockerfile when you need it

Developers submit a ZIP or GitHub snapshot. Velcio builds inside a Firecracker guest so the same isolation story covers compile time, not only runtime.

Dockerfile

Escape hatch for Go, Rust, C and custom images. Exactly one Dockerfile. Bases must pass Velcio's allowlist. Built in the guest, never on the host daemon for untrusted submissions.

Delivery format

Safer for review and handover

Isolation and builds only matter if they support the path you already use: fund, deliver, try it live, then accept.

Secrets stay with the buyer. Production secret values are encrypted at rest, set only by you and never shown to developers or returned in the API. Developers only declare which env vars are required.

Review is a live session. Velcio boots the delivery so you can click through before you accept.

Accept completes handover. You get the source. Hosting on Velcio is optional.

Money follows the same path. Authorised at fund, charged after the cooling-off window, then work.

See the workflow next

Read the buyer workflow, the delivery format, or email support@velcio.dev.

How Velcio runs your app | Velcio