Definition: Project graph
The project graph is the whole system a KERNSTACK project declares in stack.json — gateway routes, functions, workers, tables, buckets, search indexes, workflows, and secrets — instantiated per environment target and changed only through reviewed plans.
What belongs to the graph
Everything stack.json declares is a node in the project graph: a gateway route pointing at a function, the table that function writes, the search index declared over that table, the workflow whose steps call the worker. Because the graph is declared rather than discovered, the platform can state the effect of a change before it happens — that is what kernstack plan prints.
Why the graph matters more than the parts
Assembled stacks have the same parts with no graph: the route lives in one console, the permissions in another, the data in a third, and the relationships in team memory. A project graph makes relationships explicit and reviewable, which is what allows an agent to draft a change against the whole system and a person to approve its complete effect in one reading.
Frequently asked questions
Related, narrower, and live: it is one application’s complete declaration — routes, compute, data, intelligence, and collaboration — tied to one deploy target and one credit meter, rather than a general language for describing any cloud resource.
Anyone who can change stack.json and get the plan approved. Coding agents draft graph changes on agent branches; promotion to production passes the project’s deploy gate, which can require review-approved source.
Yes. Apps under apps/ build and publish into the project’s buckets on deploy, and gateway prefix routes serve them — the frontend is a node in the same graph as the API behind it.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.