Glossary
Access entry
Section titled “Access entry”The block of an Application YAML that exposes a workload to the public. Specifies a protocol (https, tcp, udp), a hostname, optionally a TLS strategy, and a policy block (auth, IP rules, rate limit, WAF). See Access, hostnames, and TLS.
The Node.js process that runs on every Edgible-managed device. Maintains a WebSocket to the control plane, reconciles desired application state with what’s running, and reports health and lifecycle events. Same binary on devices you own and on Edgible-operated cloud-hosts.
Application
Section titled “Application”The top-level deployable unit. One canonical-v3 YAML document. Bundles workloads, optional storage, and access entries on a single placement. See Applications and workloads.
API key
Section titled “API key”A bearer token issued for a single application, used by the api-key auth mode. Sent as Authorization: Bearer sk_…. Created via edgible application api-keys create.
Auth mode
Section titled “Auth mode”The policy enforced on requests to a public access entry. One of none, edgible-login, api-key, short-code. See Authentication modes.
The reverse proxy that runs on every device hosting workloads. Terminates TLS, enforces auth policies, proxies to workloads.
Canonical Application (v3)
Section titled “Canonical Application (v3)”The current YAML resource shape — apiVersion: v3, kind: Application. The model used by edgible stack deploy.
Cloud host
Section titled “Cloud host”An Edgible-operated machine that hosts tenant microVMs in a region. Users don’t provision cloud-hosts; the platform does. Cloud placement (placement.strategy: cloud) targets a cloud-host. See Cloud hosting.
Cloud placement
Section titled “Cloud placement”Running an application on Edgible-operated cloud infrastructure rather than on a device you own. Selected with placement.strategy: cloud and a region. See Cloud hosting and Deploy to cloud.
Control plane
Section titled “Control plane”The Edgible-operated backend (AWS Lambda, DynamoDB, Cognito, WebSocket API). Stores desired state; pushes updates to agents; coordinates migrations and resolves cloud placement.
Declaration version
Section titled “Declaration version”Each successful deploy of an Application creates a new immutable declaration version with a monotonically increasing number. The platform records the version for each operation; edgible application rollback reverts to a prior version.
Device
Section titled “Device”A machine running the Edgible agent that hosts workloads. Can be hardware you install the agent on (placement.strategy: serving-device) or an Edgible-operated cloud-host (placement.strategy: cloud). See Devices.
Device pool
Section titled “Device pool”A per-organization WireGuard subnet that joins all of the organization’s devices in a private mesh. See Device pools and WireGuard.
Edgible CLI / edgible
Section titled “Edgible CLI / edgible”The command-line interface, installed locally, used for everything. See CLI overview.
edgible-login auth mode
Section titled “edgible-login auth mode”Auth mode where the requester must present a valid Edgible session for a member of the application’s organization (or one of the organizations listed in policies.auth.allowedOrganizations). Suitable for internal tools.
Edgible edge / managed edge
Section titled “Edgible edge / managed edge”Public-facing infrastructure operated by Edgible. Receives public TCP traffic, terminates the public connection, looks at the SNI hostname, and forwards the encrypted stream over WireGuard to whichever device hosts the application. Users don’t run any of it.
Firecracker
Section titled “Firecracker”The microVM runtime used for cloud placement. Provides the tenant security boundary on cloud-hosts: each application runs in its own Firecracker microVM with its own kernel, root filesystem, and storage.
Generated hostname
Section titled “Generated hostname”A hostname under a platform-owned domain (e.g. <app>-<id>.edgible.app) automatically minted for an application. The alternative is a custom hostname.
Custom hostname
Section titled “Custom hostname”Any hostname you control, pointed at Edgible’s edge via DNS. See Use a custom domain.
HAProxy
Section titled “HAProxy”The load balancer running on Edgible’s edge. Routes inbound public traffic by SNI to the WireGuard tunnel for the device hosting the application.
managed-process workload
Section titled “managed-process workload”A workload type where the agent supervises a long-running native process (no container). Restart-on-failure, log capture, and lifecycle are handled by the agent.
Migration
Section titled “Migration”The platform-coordinated workflow that moves an application — including its persistent storage — from one device to another, or between a device and cloud, with the public hostname unchanged. Requires mobility: movable storage and migrationPolicy: allowed. See Migrate between devices.
Mobility
Section titled “Mobility”A property of spec.storage[] entries that controls migration eligibility. Values: immovable (default; bound to one device), movable (can be migrated), replicated (multi-device), cloud-only (lives in cloud-managed storage).
Organization
Section titled “Organization”The top-level multi-tenancy boundary in Edgible. Users, devices, applications, API keys, and the device pool all belong to one organization. The metadata.organization field on every Application is the organization ID.
Reconciliation
Section titled “Reconciliation”The agent process of comparing desired state (last known application YAML for this device) with actual state (what’s running) and applying the diff.
Serving device
Section titled “Serving device”A device you own that hosts workloads. Selected with placement.strategy: serving-device and a deviceSelector. Contrast with cloud placement.
Short code
Section titled “Short code”A rotating, time-bounded, optionally use-capped token. Used by the short-code auth mode for short-lived shared access.
Sleep policy
Section titled “Sleep policy”Configuration on spec.cloud.sleep that lets a cloud-hosted application stop after an idle period and resume on the next request. See Cloud sleep and wake.
A YAML file passed to edgible stack deploy containing one or more Application documents, optionally with metadata.dependsOn declaring inter-application order. Not a separate resource — a stack is the set of applications declared in the file. See Stack with dependencies.
Storage inventory
Section titled “Storage inventory”The platform’s per-storage-resource registry. Tracks ownership (application + workload), source (platform or host-bind), device location, size, mount state, and mobility. The basis for migration and cloud placement decisions.
Tenant / tenant microVM
Section titled “Tenant / tenant microVM”In cloud placement, the per-application Firecracker microVM that hosts a single application’s workload. Tenants do not share a kernel, network namespace, or storage; the microVM is the security boundary.
TLS (managed by Edgible)
Section titled “TLS (managed by Edgible)”The platform requests, installs, and rotates certificates for https access entries. The default for new applications. The alternative is tls: { managedBy: passthrough }, where the workload terminates TLS itself.
WireGuard
Section titled “WireGuard”The encrypted VPN protocol that connects every device in an organization to Edgible’s edge and to each other through a per-organization device pool.
Workload
Section titled “Workload”The thing inside an Application that actually runs your code. One of five types: compose, docker, managed-process, vm, pre-existing.