Production

Partly available

Production as a part of a project is not an object of the API yet. What exists today: an agent token of class production may only read, and a deploy that makes the app worse is rolled back on its own. The platform does not yet know which app is production; the token’s class and app list say it.

What your agent may do

• Read without asking: logs, releases, and read-only SQL.
• Change what can be undone: a deploy that can be rolled back, a promote from a twin.
• Ask you before anything irreversible, see Confirmations.

Whether an agent may read production data at all will be a setting, because production holds your customers’ data.

Safety nets

• Watching after a deploy. For five minutes after the switch, Rytiv compares the app’s error rate (the share of 5xx answers, with at least 20 requests to judge) with the rate before. If it is clearly worse, the deploy is rolled back on its own; the verdict is in the deploy’s watch field.
• The database is never rolled back automatically. A point-in-time restore is offered instead, and the state before a restore is kept as a branch.
• A restore point before every production migration comes with projects.

What exists today

• Rollbacks of an app to an earlier release, without a rebuild, by hand and automatically after a bad deploy.
• Point-in-time restore of a database in place, with the old state kept as a branch.
• Read-only SQL for your agent: without a branch, execute_sql runs in a read-only transaction.
• An agent token of class production, which may read and nothing else.