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. |
| Paused | The pod is scaled to zero and workload access is revoked, but recoverable app resources are retained. (suspended on the API.) |
| Queued for deletion | IT has requested deletion and the app is being torn down in the background. Usually brief. If a teardown step fails, the app stays here and the detail page says which step is stuck and how long it has been queued — IT can retry it from the app’s power menu. |
| Deleted | IT has permanently retired the app. Runtime resources are removed and the repo is archived. |
Pausing and restoring an app is available from its detail page — to you as its owner, and to IT through the kill switch. Pause your own app while you rebuild it and restore it when you’re ready. You cannot delete an app yourself; that’s an IT action for permanently retiring an app.
If your organization has turned it on, an app can also be paused for going unused. When your app goes quiet you’ll get one email saying it is scheduled to be paused, and the app’s own page shows the same warning with the two things that stop it: open the app (using it is what resets the clock) or confirm it is still needed. Deploying it counts too. Nothing is deleted automatically, and a paused app can be restored from its page whenever you want it back. Your organization sets the timings, and can exempt an app that is idle by design.
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). Paused 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.md remain with the app, while Knowledge is reserved for context worth carrying into future sessions. The agent authors the README unprompted on a new app (Quick Start, Commands, Architecture, Contributing) the same way it authors the dashboard icon — you do not have to ask for one.
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.
Your company’s logo, not an invented one
Section titled “Your company’s logo, not an invented one”Knowledge entries can carry image files as well as text, and IT usually attaches the company logo, icon, and favicon to the org design-system entry. Your agent checks there before putting your company’s mark anywhere in the app, copies the real file into your app’s repository, and commits it — so the header has your actual logo rather than something that merely looks like one.
If nothing is attached, the agent leaves the company mark out rather than drawing an approximation. An empty spot where a logo belongs means IT has not added the files yet — ask them to attach the logo to org Knowledge, and every app built afterwards picks it up.
Your app’s own icon is different: that is the app’s identity rather than the company’s, so the agent will design one if the organization has no icon attached.