Cloud hosting

By default, Edgible runs your applications on devices you own. Cloud placement is the alternative: you keep the same YAML, the same access entries, the same auth modes, and Edgible runs the workload in a managed Firecracker microVM in the region you choose.

spec:
  placement:
    strategy: cloud
    region: us-east-1

This page covers what cloud placement is, when to use it, and the cloud-only features that come with it (sleep/wake, cloud-managed storage).

What runs where

When you deploy with placement.strategy: cloud, the platform schedules your application onto a cloud-host — an Edgible-operated Linux machine in the chosen region — and provisions a per-application tenant microVM under Firecracker. Your workload runs inside that microVM. From your application’s perspective the model is identical to a serving device: the same Caddy + WireGuard mesh, the same access entries, the same auth modes.

Tenants are strictly isolated. Each application gets its own microVM with its own kernel, root filesystem, network interface, and storage. Tenants do not share a kernel or memory; the microVM boundary is the security boundary.

The path of a public request is the same as for a device you own: traffic enters through Edgible’s edge, traverses an encrypted tunnel to the cloud-host, and is forwarded to your tenant microVM where TLS terminates and auth is enforced. The only difference is who provisioned the box at the other end.

When to use cloud placement

Use cloud placement when you want a public service without operating hardware yourself. Common cases:

• You’re prototyping and don’t want to install the agent on a machine yet.
• You need a service in a region where you don’t have a device.
• You want the workload to sleep when idle (cloud-only).
• You want Edgible to handle storage durability and backups (cloud-only, on the roadmap).

Stick with serving-device placement when:

• The workload runs on hardware you already operate (workstation, on-prem server, edge box).
• You want full control over the host kernel, host packages, or host networking.
• The workload needs hardware Edgible’s cloud doesn’t yet expose (specialised GPUs, USB devices, etc.).

You can mix and match within an organization — different applications can target different placements.

Sleep and wake

Cloud-hosted applications can be configured to sleep when idle and wake on the next request:

spec:
  placement: { strategy: cloud, region: us-east-1 }
  workloads: [ ... ]
  cloud:
    sleep:
      enabled: true
      idleAfter: 5m
      wake: sync
    minActive: 0

When sleep is enabled, Edgible stops the tenant microVM after idleAfter of no active connections. The first request that arrives while the tenant is asleep wakes it back up — sync blocks the request while the wake completes, async returns immediately and replays the request once the workload is ready. Persistent storage stays attached across sleep cycles.

minActive: 0 allows the tenant to fully sleep; setting it to 1 keeps at least one instance always-on. Sleep is only meaningful for cloud placement (a serving device you own is always running) and is rejected by validation on serving-device placement. See Cloud sleep and wake for tuning guidance.

Storage on cloud

Cloud placement supports the full spec.storage[] model. The mobility field constrains where the volume can live:

• cloud-only — the volume is provisioned and managed by Edgible cloud storage. Required if you want the application to have persistent state in the cloud.
• movable — eligible for migration into the cloud from a serving device, or back out.
• immovable and replicated — work for serving placement; cloud-only is the typical choice for new cloud deployments.

A cloud-only volume is rejected by validation on a serving-device placement, and vice versa — the schema enforces that the storage class matches the placement.

If you’re moving an existing application from a device into cloud and the application uses Compose bind-mounts (data lives on the host filesystem), the platform tracks those as host-bind storage records. Bind-mounts can’t run on cloud directly — promote them to platform-managed storage with edgible application storage promote first, then change the placement.

Logs and observability

Logs from a cloud-hosted tenant flow back to the platform automatically. edgible application logs <app-id> works the same way it does for serving placement; the agent on the cloud-host tails the tenant’s serial console and forwards lines to the control plane.

Limits

Today’s cloud beta has a few practical limits worth knowing about:

• One cloud-host per region. Edgible operates one cloud-host VM per supported region; placement is deterministic. Multi-host horizontal scale per region is on the roadmap.
• Stop-start sleep. Sleep stops and restarts the tenant microVM. Pause/resume snapshot/restore is on the roadmap.
• Promotion is one-way. host-bind storage can be promoted to platform storage; the reverse isn’t supported.
• Region availability rolls out gradually. If a region isn’t yet supported, deploys with that region are rejected by the control plane.

Authoring a cloud application

Minimal example:

apiVersion: v3
kind: Application
metadata:
  name: cloud-hello
  organization: <org-id>
spec:
  placement:
    strategy: cloud
    region: us-east-1
  workloads:
    - name: web
      type: compose
      composeFile: ./docker-compose.yml
      ports:
        - { name: http, containerPort: 8080, protocol: tcp }
  access:
    - name: public
      type: https
      target: { workload: web, port: http }
      hostname: { generated: true }
      tls: { managedBy: edgible }
      policies: { auth: { mode: none } }

Walkthroughs: Deploy to cloud, Cloud sleep and wake.