Ops platform / Concepts
Resources
Everything a project runs is a resource with a name, a spec and a status.
A resource is one thing ops runs or holds for your project. Each has a type, a name, a spec (what you asked for) and a status (what ops sees). Ops keeps them in step: it applies the spec, watches the result, and shows the state as a dot and one line.
| type | what it is | lives in |
|---|---|---|
| Service | a container built from your repository | an environment |
| Database | Postgres, MariaDB, libSQL or SQLite | an environment |
| Domain | a hostname with DNS and a certificate | an environment |
| Secret group | variables handed to services at start | an environment |
| Bucket | object storage, with its keys in a secret group | the project |
| Job | a container run on a schedule | an environment |
| Network | the environment's private network, made with it | an environment |
| Packages | the package names the project may publish, see Packages | the project |
Add one with Add resource on the project's overview, or on the type's own page.
ops resources lists every resource of an environment with its state.
Where a spec comes from
A service, a domain and a step can be declared in the project file. What the file sets is read only in the console for that environment, with a link to the file; change it with a commit. What the file leaves out stays yours to set in the console. Databases, secret groups, buckets and jobs are made in the console or through the API.
Removing one
Deleting a resource asks for its name typed back. Ops refuses a delete that would leave something running unmanaged, or lose data, and says why: a bucket that still holds objects, or a repository a service still builds from.
A resource the project file stops declaring keeps running and is listed as no longer declared, so you delete it on purpose.
History
Every change to a resource is kept with who made it. The resource's page lists them, and the audit log holds every action taken in the project.