Staying in Control
AstroPulse lets people and Nova change production through one API. That only works if you stay in control, so control is built into the platform rather than added on top. How your cloud access, secrets and keys are protected is on Security. Five things work together:
| What it gives you | Read more | |
|---|---|---|
| Your cloud | Everything runs in cloud accounts and clusters you own | Deploy a cluster, Bring your own cluster |
| Roles | Each person and API key can do only what its role allows | Organizations |
| Approvals and guardrails | Sensitive changes wait for a person to say yes | Cluster approvals, Nova guardrails |
| Audit | Changes are recorded: who, what, when and from where | Audit Logs |
| Rollback | A bad change can be undone, and you see the diff first | Application rollback, Add-on rollback |
It runs in your cloud
Your clusters run in your own cloud accounts, or they are clusters you already run and register with AstroPulse. Your applications, models and data stay there. AstroPulse manages them; it does not move them.
Every person and key has a role
Everyone in an organization has a role: owner, admin, editor or viewer. An API key carries its organization and a role too, so a script, a CI pipeline or your own product can do exactly what its key allows and nothing more. See Organizations.
Sensitive changes wait for approval
Two kinds of change wait for a person:
- New clusters. When an admin creates a cluster, it waits for an owner to approve it before any infrastructure is created. Owners approve from the email or the console. See Cluster approvals.
- Nova's changes. Nova works under your organization's guardrails. By default it reads freely, asks before it deploys, scales, provisions or reads logs, and never deletes or touches secrets. See Guardrails and Approvals.
When something goes wrong, stop everything
If Nova is doing something you did not expect, an owner or admin can turn on emergency stop. It blocks every write Nova makes across the organization at once, while Nova can still read and investigate. To trial a stricter policy without blocking anyone, use shadow mode, which records what would have been blocked. Both are in Guardrails and Approvals.
Changes are recorded
- Audit Logs record changes to your clusters, applications, profiles, organization and API keys: who made each one, when, from which IP address and client, and whether it succeeded. They are recorded at the API, so they cover every way in: the console,
astroctl, the API and SDKs, and Nova. Audit Logs are on the Enterprise plan. See Audit Logs. - Nova's activity records every decision Nova made: what it wanted to do, whether it ran, needed approval, was approved, denied or blocked, and who decided. See Guardrails and Approvals.
A bad change can be undone
- Applications. Every deploy is kept as a version. Roll back to any earlier good version from the console,
astroctlor Nova. You always see what will change before you confirm, and history is never rewritten. See Rollback & Deploy History. - Add-ons. Every add-on keeps its history, and you can roll back to an earlier revision, with a preview first. See Managing add-ons.
- Kubernetes upgrades are one-way on a managed control plane. On EKS, GKE and AKS the control plane stays at its new version; a rollback only returns the nodes. Plan upgrades and try them on a non-production cluster first.
Who can reach what you expose
A model you expose outside the cluster requires an access policy, so every caller must present a valid API key or token. See Access Policies.