Deploy to cloud

This guide deploys a small web service into Edgible-operated cloud — a Firecracker tenant microVM in the region you choose. The YAML differs from a serving-device deploy in exactly one block: placement.

Prerequisites

• An Edgible account, logged in (edgible auth login).
• A region your organization can deploy into (the platform tells you on first apply if the region you pick isn’t available).
• A docker-compose.yml for the workload you want to run.

You do not need the agent installed locally — cloud deploys go through the platform. The CLI just authors and submits the declaration.

A minimal cloud application

Save as app.yml:

app.yml

apiVersion: v3
kind: Application
metadata:
  name: cloud-hello
  organization: <your-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 } }

A matching docker-compose.yml for testing:

docker-compose.yml

services:
  whoami:
    image: traefik/whoami
    ports:
      - "8080:80"

Deploy:

edgible stack deploy -f app.yml

The control plane validates the YAML, picks a cloud-host in the requested region, builds a per-tenant rootfs that includes your compose file, boots a Firecracker microVM, and configures the public route. First boot typically takes 30–90 seconds.

Watch progress:

edgible stack status -f app.yml

When the application is ready, the same output shows a generated hostname (something like cloud-hello-a1b2c3.edgible.app). Hit it:

curl https://cloud-hello-a1b2c3.edgible.app/

Cloud + persistent storage

Add a spec.storage[] entry with mobility: cloud-only and mount it on the workload:

spec:
  placement:
    strategy: cloud
    region: us-east-1
  storage:
    - name: data
      type: persistent
      size: 1Gi
      mobility: cloud-only
  workloads:
    - name: web
      type: compose
      composeFile: ./docker-compose.yml
      ports:
        - { name: http, containerPort: 8080, protocol: tcp }
      storage:
        - name: data
          mountPath: /mnt/edgible/data
  access: [ ... ]

The platform attaches the volume to the tenant microVM and mounts it at the path you specify. Data survives edgible application restart and survives sleep cycles (see Cloud sleep and wake).

mobility: cloud-only is rejected on serving-device placement and required only when you want the volume to live exclusively in cloud storage. If you also want the application to be migrated into cloud from a device you own, use mobility: movable instead — see Migrate between devices.

Cloud + auth

Cloud placement supports the same four auth modes as serving placement. Switch on API-key auth:

access:
  - name: public
    type: https
    target: { workload: web, port: http }
    hostname: { generated: true }
    tls: { managedBy: edgible }
    policies:
      auth: { mode: api-key }

Mint a key:

edgible application api-keys create --app-id <app-id> --name "test-key"

Call it:

curl https://cloud-hello-a1b2c3.edgible.app/ \
  -H "Authorization: Bearer sk_<the-key>"

For details, see Protect with API keys.

Cloud + organization-only auth

Restrict to members of one or more organizations:

access:
  - name: internal
    type: https
    target: { workload: web, port: http }
    hostname: { generated: true }
    tls: { managedBy: edgible }
    policies:
      auth:
        mode: edgible-login
        allowedOrganizations: [<org-id-a>, <org-id-b>]

Visiting in a browser triggers a sign-in flow; if the user belongs to one of the listed orgs, they’re let through.

Logs

edgible application logs <app-id> --follow

Logs from the tenant’s stdout/stderr stream back to the platform automatically.

Teardown

edgible stack teardown -f app.yml

The application is removed; the tenant microVM is stopped and its rootfs discarded; storage volumes are released.

Limits worth knowing

• One cloud-host per region today. Placement is deterministic; horizontal scale within a region is on the roadmap.
• Pick a region the platform supports. If you specify a region that isn’t yet hosted, the apply is rejected with a STORAGE_CLOUD_NO_HOST error — change region and re-apply.
• Compose bind-mounts can’t run on cloud directly. If your compose file uses ./data:/...-style mounts, promote them to platform storage before changing placement to cloud (see Cloud hosting).