On this page
flight
About Retrojet
Why Retrojet exists, how it is built, and the rules it follows.
Why
A one-line fix in a Flutter app can take days to reach users: build, submit, wait for review, wait for users to update. Retrojet shortens that path for Dart changes. You still ship releases through the stores, and between releases you send patches straight to the devices that run them.
How it is built
| Part | Built with | Role |
|---|---|---|
| CLI | Go, one static binary per OS | Sign-in, project setup, building and uploading releases and patches |
| Backend | Java, Spring Boot, PostgreSQL | Accounts, organizations, apps, releases, patches, channels, usage |
| Console | Next.js, React, Tailwind CSS | The web app your team uses to check, promote, and roll back |
| These docs | Hugo with the Lotus Docs theme | Static pages, no server code |
Rules we keep
- The CLI creates, the console controls. Releases and patches are only made from the CLI, where the build happens. The console can promote, roll back, and delete, so a browser is enough to react when something breaks.
- Rollback is per channel. Stopping a patch for testers never touches what your users on
stablerun. - Tokens stay out of the browser. CLI sign-in uses PKCE, so the token goes straight from Retrojet to your terminal. The console keeps your access token encrypted in an HttpOnly cookie that page scripts cannot read.
- Patches are signed. Every patch file is uploaded with a signature.
- Honest docs. If something is not available yet, the page says so.
Status
Retrojet is in early access. The console, sign-in, and project setup work today. Building releases and patches from the CLI is in progress. See What is Retrojet for the current state.
Credits
These docs are built with Hugo and the Lotus Docs theme by Colin Wilson. The console started from next-shadcn-admin-dashboard-aria by Mohammed Arham Khan. Full license details are on the License page.