This section explains how Helix fits together before you build on it. Four pages cover where your code runs, how the platform is organized, how a project names its deploy targets, and why the credential model holds up to security review. Each page stands alone, so read in order or jump to the one you need.
The four pages
| Page | The mental model it gives you |
|---|---|
| How Helix works | Same code, two runtimes: a local Nitro dev server during development, one AWS Lambda per project in production, shared platform services behind both. |
| Projects and workspaces | A three-level hierarchy: organizations contain workspaces, workspaces contain projects, and permissions attach to the workspace. |
| The configuration model | One config file describes one deploy target. More targets means more files, never merging. |
| Security model | Code references credentials by alias; the platform stores, injects, and logs them. Secrets never enter your repository or runtime. |
Where to go next
If you have not built anything yet, start with What is Helix and the quickstart. When you are ready to ship, the deployment guide turns these concepts into commands.