App deployment & isolation

Concept

When you register a new app in Greenlight, the platform creates a dedicated place for it to run — separate from every other app in your organization. If the app needs a database or object storage, the coding agent requests those resources and Greenlight provisions them. Postgres is reached through DATABASE_URL; blob storage is reached through the data broker (GREENLIGHT_PROXY_URL + GREENLIGHT_DATA_KEY).

The app brings the code; Greenlight brings isolation boundaries, the image registry, network policy, workload identity, and lifecycle management.

At registration

Every registered app gets these resources, provisioned in your cloud environment. The app never holds cloud admin credentials.

Resource	What it gives the app	What it isolates
Kubernetes namespace (gl-app-<slug>)	The boundary the app’s pods run in.	No cross-namespace traffic; no cluster-level RBAC.
Deployment boundary	A governed place to build, deploy, and reach the app at its org subdomain after the first successful deploy.	Each app’s runtime and URL are separate from other apps.
Image repository	The built container image is pushed here on every pipeline pass.	One repository per app; pull credentials are managed by the platform.
NetworkPolicy	Ingress from the SSO-enforcing controller plus narrowly selected Greenlight verification and imagery services; egress to the data broker and the app’s own resources.	A compromised app cannot pivot to other apps, the control plane, or the public internet.
ResourceQuota	A namespace-level CPU, memory, and storage ceiling.	One app’s load can’t starve others.
Workload identity	The credential the app uses to authenticate to the data broker.	Per-pod, signed by the cluster, rotated automatically. Never stored in app source code.

When the app needs storage

If the app needs durable data, the coding agent asks Greenlight to add a database, file storage, or both:

Resource	What it gives the app	What it isolates
Postgres database	Durable storage, injected as DATABASE_URL.	A scoped database user; the app cannot see other apps’ databases. Private network path only.
Object storage container	Blob storage for uploads, exports, and backups, reached through the data broker.	Objects stay in this app’s container; the app cannot list or read other apps’ storage.

Greenlight creates the resources and the app reaches blob storage through the same data-broker pair as integrations (GREENLIGHT_PROXY_URL + GREENLIGHT_DATA_KEY) via a small module copied from the storage Skill. Local development uses the same path; see App environment variables. Later deploys reuse the same storage.

greenlight.yml in the app repo holds identity and documentation — not a list of infrastructure to provision. Agents configure resources through the MCP tools reference.

Note

On the roadmap, the same request-and-provision pattern extends to more managed capabilities:

• Redis — caching, sessions, and job queues
• Outbound email — governed sending so apps can notify users without holding mail credentials
• Search — a per-app index for in-app search features
• Additional deployment shapes — background workers, scheduled jobs, static sites, and other compute types beyond the default web server every app gets at registration today

Lifecycle states

Dedicated resources move with the app through the governed deployment lifecycle.

Status	Namespace	Postgres	Object storage	Image repo
Registered	Created	When requested	When requested	Created on first build
Building / Deploying	Preparing rollout	Preparing	Preparing	Building image
Active / Degraded	Running	Active	Active	Active
Failed	Preserved for retry	Preserved	Preserved	Preserved
Paused	Scaled to zero	Preserved, idle	Preserved	Preserved
Deleted	Deleted	Dropped	Deleted	Deleted

Restore from Paused brings the app back with its data intact. Delete is the permanent retirement path: runtime resources are torn down and the source repo is archived (not deleted) to preserve history. A configurable retention window that holds the database for a recovery period before dropping it is planned but not yet available.

Caution

The kill switch moves an app to Paused by scaling it to zero and revoking workload access. The database, object storage, repo, and audit history are preserved. Delete is the destructive option — used when an app is being retired permanently.

What network policy enforces

The NetworkPolicy attached to every app namespace allows these platform-controlled flows and blocks the rest:

• Ingress is permitted only from the cluster’s ingress controller, which terminates TLS and enforces SSO before traffic reaches an app pod.
• Internal verification and imagery are admitted only from the Greenlight control-plane server and renderer pod identities. This lets the agent verify a deployed response and lets Greenlight capture app imagery without opening app-to-app traffic.
• Egress to the data broker for any upstream HTTP call, which is how an app reaches a SaaS API without ever holding its credential.
• Egress to the app’s own Postgres on the database port, via a private endpoint inside the cluster’s VNet.

Pod-to-pod traffic across namespaces is blocked at the policy layer. Outbound restriction is off by default, so public-internet egress and the cloud metadata service are currently reachable from an app pod — Network isolation sets out what holds today and what an org admin can turn on. The broker remains the only path that carries an upstream credential, so it is the only way an app reaches a SaaS API with access.

Resource quota

Each namespace gets default CPU, memory, and ephemeral-storage caps configured by IT in the org policy bundle. Apps that need more than the defaults file a request through the dashboard, which an IT admin approves and which is then captured as a policy override in the audit log.

Next

Building blocksWhere workloads and resources fit among the other primitives.

Network isolationThe NetworkPolicy specifics from a security review.

Kill switch & restoreThe IT-admin workflow for stopping and bringing back apps.

Data brokeringThe egress endpoint apps actually talk to.

greenlight.ymlIdentity and docs metadata in each app repo.