Reference manuals, build schemas, and credential variables for deploying inside isolated virtual micro-VM runtimes.
DEVELOPMENT DEPLOYER orchestrates secure, isolated build-pipeline runtimes for corporate GitOps streams. By utilizing isolated Firecracker micro-VM containers, workloads execute statelessly without cross-contamination. Unlike traditional containers that share the host kernel, every DEVELOPMENT DEPLOYER build executes inside a dedicated micro-VM. These micro-VMs boot in less than 5 milliseconds, mount a read-only root filesystem, and use jailer processes to restrict jail-break attempts. The host kernel is shielded, preventing cross-tenant leakage or persistent compromised footprints.
SECURITY COMPLIANCE REQUIREMENT: The gateway is configured with hard-coded filters that restrict environment boot actions to verified business entities. Public-domain email assertions (e.g., Gmail, Outlook, Hotmail) will result in immediate termination during the handshake phase.
The runner architecture splits execution into two domains: the untrusted runtime and the trusted hypervisor controller. Workloads operate strictly inside the untrusted guest boundaries, communicating with the host via ring buffers over virtual sockets (vsock).
Before integrating your repositories with the gateway, verify that your environment satisfies the following infrastructure constraints:
The DEVELOPMENT DEPLOYER Command Line Interface (CLI) is compiled statically for all major operating systems. Select your platform below to download and install the agent locally:
macOS (Homebrew Package Manager)
Linux (Debian / Ubuntu Systems)
Windows (Microsoft PowerShell Console)
To provision staging or production environments, construct a compliance access file referencing your corporate ID, vault secrets, and metadata definitions. Initialize your system:
Single Sign-On (SSO) gates operate under strict OIDC guidelines. Workspaces authenticate via scoped corporate identity servers. Public identity providers (such as Gmail, Yahoo, or Outlook) are blocked by default at the edge firewall level to enforce organizational perimeter control.
When a session handshake is requested by a client CLI agent or Web Portal, the gateway starts a multi-step identity token exchange:
SSO sessions utilize hardware-backed passkeys. Authentication assertions are signed locally on user devices and validated using registered public keys. Plaintext passkeys are never transmitted across the network, ensuring zero exposure to eavesdropping. The client device receives a random cryptographic challenge, signs it using its internal secure chip, and returns only the signature.
Upon successful assertion, the security token has a lifetime of exactly 15 minutes. This window is strictly enforced by the server kernel. If a deployment operation fails to check-in within this countdown window:
Pipeline execution parameters are declared in standard config formats (YAML). Runtimes dynamically inject secrets from registered vault scopes directly to ephemeral micro-VM memories during sandbox bootstrap.
The `devdep.yaml` file controls core resource bounds, rootfs configurations, OIDC bindings, and vault endpoints. Review the production configuration schema below:
DEVELOPMENT DEPLOYER enforces strict zero-persistence mechanics for secret keys. Credentials mapped from your provider are injected directly into the kernel memory space of the micro-VM guest. The hypervisor creates an anonymous, unlinked memory file descriptor using `memfd_create` and flags it with `MFD_CLOEXEC`.
The filesystem is mounted inside the sandbox as a ramfs partition. Because it resides entirely in RAM, the credentials vanish instantly on container tear-down, leaving zero trace of security parameters in standard system logs or physical disks.
Build jobs run within three strictly separated execution segments:
| Hook Name | Execution Boundary | Description |
|---|---|---|
pre_bootstrap |
Host Controller | Sets up system resources, maps network namespaces, and downloads OIDC metadata to build the trust zone. |
run_command |
Isolated Guest VM | Compiles source code, runs integration suites, and packages binaries within the read-only micro-VM sandbox. |
post_teardown |
Host Controller | Destroys virtual interfaces, unlinks memory blocks, updates cryptographic hashes, and publishes signed telemetry reports. |
DEVELOPMENT DEPLOYER routes traffic globally to edge distribution points with sub-millisecond route propagation. The system's ingress controller utilizes Anycast routing to distribute traffic to the physically nearest healthy container.
By utilizing Border Gateway Protocol (BGP) Anycast routing, client requests hit the physically closest edge node. If a regional node encounters performance degradation, automated path checkers instantly adjust BGP weights, rerouting packets to adjacent network gateways without session interruptions.
Every request between CLI agents, vault environments, and API endpoints is encrypted with mTLS (Mutual Transport Layer Security).
Ingress nodes continuously measure path latencies. If a route exceeds nominal threshold limits, traffic is instantly redirected:
The devdep-cli executable is the primary command-line utility for managing corporate gateway configurations, triggering tests, and auditing network runtimes.
| Command Syntax | Options & Flags | Purpose |
|---|---|---|
devdep-cli auth |
--provider, --token |
Authenticates the local terminal context with the enterprise OIDC gateway. |
devdep-cli init |
--entity, --domain, --out |
Creates a fresh, pre-configured devdep.yaml metadata profile. |
devdep-cli validate |
--file |
Verifies syntax and matches secrets references against the vault database. |
devdep-cli deploy |
--env, --timeout |
Boots the micro-VM, checks certificates, executes pipelines, and tears down the VM. |
devdep-cli status |
--ticket |
Audits session lifespan parameters and verifies active IP footprints. |
devdep-cli network |
check-routes, --verbose |
Runs route latency measurements across geographic ingress endpoints. |
Automated pipeline integrations evaluate CLI execution status codes. Below are the standard return codes:
| Exit Code | Identifier | Description & Action Required |
|---|---|---|
0 |
SUCCESS |
Execution completed without errors. No action required. |
101 |
ERR_OIDC_TIMEOUT |
The trust verification handshake expired. Re-authenticate via SSO. |
102 |
ERR_DOMAIN_RESTRICTED |
Public domains are blocked. Login with a provisioned corporate domain email. |
201 |
ERR_VAULT_MISMATCH |
Ingress could not resolve the Vault endpoint. Verify host endpoint or token permissions. |
301 |
ERR_VM_BOOT_FAILED |
Host hypervisor initialization failure. Contact on-premise system support. |
401 |
ERR_EGRESS_VIOLATION |
Sandbox program attempted to call unapproved external IPs. Audit egress routes. |
DEVELOPMENT DEPLOYER integrates into enterprise workflow orchestration engines. Rather than storing static gateway keys in pipeline variables, we recommend utilizing OpenID Connect (OIDC) federation to verify identity at execution runtime.
Configure a workflow file under .github/workflows/devdep.yml. Ensure that the permissions block includes id-token: write to allow token generation:
Configure a workflow inside .gitlab-ci.yml using the federated identity token system:
Solutions to common problems, firewall logs configuration, and authentication issues.
Q: Why does my authentication request return "CRITICAL ERROR: INVALID_ENTITY_DOMAIN"?
A: The DEVELOPMENT DEPLOYER edge gateway blocks any credentials linked to public domain structures. Verify that you are logging in with your official corporate identity credentials provider account. If your corporate domain is new, contact your network administrator to whitelist your domain in the gateway registry database.
Q: What happens if the compliance ticket countdown timer runs out?
A: When the 15-minute window expires, the issued OIDC SSO session is immediately revoked, and any micro-VM sandbox container running under that session signature is terminated. To resume work, you must execute a fresh SSO handshake via the authentication portal.
Q: Can I run custom Docker images inside the micro-VM runner?
A: Yes. DEVELOPMENT DEPLOYER supports loading custom base OS images. However, the image must be converted to an uncompressed root filesystem block image (.ext4) and signed with your corporate security key before ingestion.
Q: How does the system handle secrets rotation?
A: If key_rotation: automatic is configured, the gateway queries HashiCorp Vault during vm boot. If a secret has changed, the VM is hot-reloaded with the new credentials injected into memory without causing downtime.
Q: The CLI returns error 401 (Egress Violation). How do I resolve this?
A: This indicates that your build process attempted to query a network address not whitelisted in the pipeline's sandboxing rules. Check your devdep.yaml settings and add the necessary IP domains or services to the approved outbound metadata mapping properties.