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 with scoped credentials.

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:

Greenlight provisions these resources in your cloud subscription. 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	Egress to the data broker only; ingress only from the SSO-enforcing controller.	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.	Credentials are bound to this container; the app cannot list or read other apps’ storage.

Greenlight creates the resources, mints scoped credentials, and injects connection settings into the running app. Local development can use the same data when your org allows it; 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
Suspended	Scaled to zero	Preserved, idle	Preserved	Preserved
Decommissioned	Deleted	Retained 30 days then deleted	Deleted	Deleted

Restore from suspended brings the app back with its data intact. Decommission is the permanent retirement path, and it includes a configurable retention window for the database.

Caution

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

What network policy enforces

The NetworkPolicy attached to every app namespace allows three 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.
• Egress to the data broker for any upstream HTTP call. Apps cannot reach SaaS APIs directly.
• Egress to the app’s own Postgres on the database port, via a private endpoint inside the cluster’s VNet.

Everything else — pod-to-pod across namespaces, public-internet egress, the cloud metadata service — is blocked at the policy layer.

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

Network isolation The NetworkPolicy specifics from a security review.

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

Data brokering The egress endpoint apps actually talk to.

greenlight.yml Identity and docs metadata in each app repo.