Your app
For citizen developers
Every Greenlight app moves through a governed deployment lifecycle, and it can accumulate a set of notes — Knowledge — that your agent checks at the start of every session. This page covers both: what the statuses mean, and what to write down so the second conversation about your app is smarter than the first.
The lifecycle
Section titled “The lifecycle”The dashboard shows the current status on the app’s detail page; the agent surfaces transitions in your chat.
| Status | What it means |
|---|---|
| Registered | The app record and repo exist, but nothing is deployed yet. |
| Building | The pipeline is building the container image. |
| Deploying | Greenlight is rolling the app out and preparing its URL. |
| Active | The app is running. End users can sign in and use it. |
| Degraded | The app is reachable but failing health checks or crash-loop thresholds. |
| Failed | The build or deploy failed. The agent can read the failure detail and try again. |
| Suspended | The app is paused. The pod is scaled to zero and workload access is revoked, but recoverable app resources are retained. |
| Queued for deletion | IT has requested deletion. The app is being torn down in the background; this is a brief transitional state before Deleted. |
| Deleted | IT has permanently retired the app. Runtime resources are removed and the repo is archived. |
Suspending and restoring an app is IT’s control — the kill switch. If you want your own app paused while you rebuild it, ask IT to suspend it (and to restore it when you’re ready). You cannot delete an app yourself; that’s an IT action for permanently retiring an app.
What end users see: while the app is Registered, Building, Deploying, or Failed, its URL isn’t available yet. Active and Degraded apps work normally (degraded ones may be unstable). Suspended apps show a short “this app is paused” message; deleted apps’ URLs are gone.
Following the build
Section titled “Following the build”The agent reports progress as it works. The dashboard’s app detail page has a Pipeline tab that shows every pull request, its policy-check result, and (on merge) its deploy. You can watch the build land in real time, or come back later and read the history.
If a pull request fails the policy check, you don’t need to do anything. The agent reads the failure and tries again. Repeated failures on the same check are worth flagging — that usually means the agent has misread what the policy expects, and a quick conversation in chat sorts it out.
Your app’s Knowledge
Section titled “Your app’s Knowledge”New apps start with no app Knowledge. That is intentional: the short deployment documentation in greenlight.yml and the repo README remain with the app, while Knowledge is reserved for context worth carrying into future sessions.
You can create the first entry from the app’s detail page, and the agent proposes additions as it discovers useful facts. Common topics include Architecture — what the app is built with and why — and Runbook — the hard-won details needed to operate or debug it. You can edit any entry to fix a wrong assumption, add a detail the agent missed, or write down a gotcha you discovered.
What you might add
Section titled “What you might add”You don’t have to add anything. But a few things tend to help:
- What “done” looks like. “This app is for the finance team during their monthly close. It doesn’t need to be fast the rest of the month.”
- Decisions you’ve made. “We decided to do email notifications, not Slack. Slack is too noisy for this team.”
- Gotchas you’ve discovered. “If the Snowflake query takes more than 5 seconds, switch to the materialized view; the live data is fine being a few minutes stale.”
- People to ask. “The product manager for this is Priya. Anything about scope, ask her first.”
The agent reads everything you write here at the start of the next session. It’ll catch a lot of “wait, why is the agent suggesting that?” moments.
When the agent proposes a change
Section titled “When the agent proposes a change”As the agent builds, it sometimes learns something it thinks is worth remembering. When that happens, it proposes a Knowledge change — a new note, or an edit to an existing one. The proposal shows up in the dashboard for you to accept, edit, or reject. Proposals stack up and you can review them on your schedule. The agent doesn’t write directly; it always proposes, and you decide.
Org and integration Knowledge
Section titled “Org and integration Knowledge”There are two other kinds of Knowledge you’ll occasionally bump into:
- Org Knowledge — IT’s notes about how your organization works. Conventions, design system, security policies. You can read these but only IT edits them.
- Integration Knowledge — notes attached to a data source, like Snowflake or GitHub. What warehouses your app can use, idiomatic queries, common errors. Catalog and custom sources both start empty until someone adds the first useful note. You and the agent can propose changes; IT reviews them.
The agent reads all three kinds whenever it works on your app.