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 these resources, provisioned 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	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.	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
Deleted	Deleted	Dropped	Deleted	Deleted

Restore from suspended 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 suspended 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. 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

Building blocks Where workloads and resources fit among the other primitives.

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.