Manage environments and routine operations
Use Production, Staging, and Development deliberately, including start, stop, clone, and neutralize actions.
Give each environment one purpose
Use Production for live users and business data, Staging for release candidates, and Development for integration work. Separate names are useful only when access, branches, data, and operational expectations differ.
Map each stage to a deliberate Git branch. Avoid pointing every environment at the same moving branch, because that removes the promotion boundary while preserving the appearance of separation.
Routine instance actions
A provisioned instance supports start, stop, and restart actions. Each action creates a tracked deployment and writes an activity event. Wait for an active operation to finish before starting another one.
Use the instance logs and deployment history to distinguish an Odoo startup problem from a Git checkout, module update, database, or infrastructure problem.
Configuration panels expose bounded Odoo, PostgreSQL, and Nginx options. Apply changes during an appropriate maintenance window and review the resulting service behavior.
Copy data safely
Tnion.SH can copy an environment within the same project into a non-Production target. The source must be running or stopped, and Production cannot be overwritten from another environment.
The clone workflow creates a portable Odoo backup, transfers it when the target is on another registered server, restores it into the target, and neutralizes the copied database. A safety backup is taken before the target is replaced.
After a copy, verify logins, scheduled actions, outgoing email, webhooks, payment integrations, and other side effects. Neutralization reduces risk, but your team must confirm that non-production behavior matches its policy.
Review activity
Workspace activity records sensitive actions with the actor, resource, timestamp, and relevant metadata. Review it after production deployments, credential updates, restores, clones, and membership changes.
The activity history complements provider logs, GitHub history, and your change-management system. It is not a replacement for those external records.