You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: apps/docs/content/features/coding-agents.mdx
+14Lines changed: 14 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,6 +9,20 @@ import IntroAgentVisual from '@site/src/components/IntroAgentVisual';
9
9
10
10
Zerops was built on the idea of **environment parity** — giving developers the full development lifecycle, from remote development to highly available production, with the observability and developer tools for maximum flexibility, and sensible defaults so the configs stay reasonable. Turns out that's **exactly what coding agents need** to produce and iterate on production-ready applications.
@@ -179,3 +179,34 @@ Keep your access token secure and never commit it directly to your repository. T
179
179
:::
180
180
181
181
For more information about GitHub Actions, refer to the [official GitHub Actions documentation](https://docs.github.com/en/actions).
182
+
183
+
---
184
+
185
+
## Advanced: Full Lifecycle Automation
186
+
187
+
:::tip Reference repository
188
+
A complete, working example of this pattern is available at [zerops-showcase-deploy](https://github.com/zeropsio/zerops-showcase-deploy), a deployment orchestrator built entirely on GitHub Actions and the Zerops API, no Zerops CLI required. Clone it as a starting point for your own multi-environment pipeline.
189
+
:::
190
+
191
+
The workflow above deploys a single service on push to one branch. This reference repo extends that into a full lifecycle: every feature branch gets its own isolated environment, every PR gets a preview, and stage and prod stay permanent with their data intact across deploys.
| Push to a feature branch | A full isolated environment | Until the branch is deleted |
198
+
| Open/update a PR to `stage` | A full isolated preview environment | Until the PR is closed |
199
+
| Merge a PR into `stage` | Redeploys app code to the shared stage environment | Permanent, data preserved |
200
+
| Push/merge to `main` | Redeploys app code to production | Permanent, data preserved |
201
+
202
+
Permanent environments keep their databases, caches, queues, and storage across every deploy, only the application code gets updated. Ephemeral environments are created from scratch and torn down automatically when no longer needed, so every developer gets their own isolated copy of the full stack without manual cleanup.
203
+
204
+
PR previews require a `stage` branch as the pull request target; the repo's setup guide covers creating it.
205
+
206
+
### How it differs from the basic workflow above
207
+
208
+
The basic GitHub Actions setup deploys one service to one Zerops project. This pattern manages entire **projects** programmatically instead: it checks whether a project for a given branch or PR already exists, creates one from an import template if not, and deploys to it. The key safeguard is that it never deletes or recreates infrastructure on permanent environments, only ephemeral ones get torn down. This is a reference implementation, not a Zerops-managed service, so you own the repo, the GitHub Actions minutes, and the Zerops API calls it makes on your behalf.
209
+
210
+
:::tip Full setup guide
211
+
Required secrets, customizing the project template for your own services, and the complete workflow reference are all covered in the [repo's README](https://github.com/zeropsio/zerops-showcase-deploy#readme).
0 commit comments