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. The same binary runs on every device you own.
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.
Artifact
Section titled “Artifact”Content-addressed immutable bytes whose identity is its sha256:… digest — a container image, an archive, a VM disk, or a binary. A container image is just an artifact addressed by digest. Delivered to each serving device and held in a device-local content-addressed store; deduplicated across every release that references the same digest.
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.
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.
Declaration version
Section titled “Declaration version”An append-only, immutable record of one resolved application spec. Every stack deploy whose resolved content (spec + pinned image digests) differs from the current one appends a new declaration version with a monotonically increasing number; identical content is a no-op. Once a version is cut — its image tags resolved to digests and its content frozen and hashed — it is a Release. edgible application rollback <version> re-points the deployment at an existing prior release; it does not append a new version.
Deployment
Section titled “Deployment”A thin pointer naming the Release an application should be running (currentReleaseVersion), plus each device’s last fully-realized release (observedReleaseVersion). Not a heavyweight record — it moves freely: forward on deploy, backward on rollback. A redeploy (edgible application redeploy) leaves the pointer where it is and forces the release it already names to be re-realized on the device(s). The gap between the pointer and a device’s observed release is what reconciliation closes.
Device
Section titled “Device”A machine running the Edgible agent that hosts workloads. Hardware you install the agent on, targeted with placement.strategy: serving-device. 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.
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, 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 converging a device to the release its application is pointed at: fetch the current release, verify its signed manifest, realize the digest-pinned bytes, and report the last release fully realized (observedReleaseVersion). An application is converged when every device’s observed release equals the deployment pointer (currentReleaseVersion) — the predicate is observed !== current, so a rollback converges the same way a forward deploy does. Surfaced by edgible application rollout status.
Release
Section titled “Release”A cut declaration version: an immutable, digest-pinned binding of { resolved spec, artifact digests, configHash, signature }. Unpinned image tags (:latest) are resolved to concrete sha256:… digests at cut time and frozen, so a release always names exact bytes. It is the unit the agent verifies and realizes, and the thing a rollback re-points to.
Serving device
Section titled “Serving device”A device you own that hosts workloads. Selected with placement.strategy: serving-device and a deviceSelector.
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.
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 decisions.
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.