A CMS upgrade becomes interesting when it changes the things you depend on outside the editor: timestamp formats, login requirements, webhook delivery, and the meaning of a successful deployment.
The latest two oCMS minor releases cover exactly that ground. 0.29.0 arrived on October 18; 0.30.0 followed on October 24. For developers running this Go-and-SQLite CMS, the main changes are consistent UTC handling, built-in two-factor authentication, and more reliable operations. Here is the practical version.
// UTC is an integration change
Version 0.29.0 migrates parseable stored timestamps with time-zone information to UTC, across core and module tables. It also returns UTC in REST responses, webhook payloads, and exports, and displays dates in UTC in the admin and public interfaces.
2026-10-18T05:41:31+02:00 becomes 2026-10-18T03:41:31Z. Same instant, different representation. Check consumers that compare strings, assume the server's offset, or display the raw value without conversion.
There is an important migration boundary: zone-free timestamps are left alone, including Internal Analytics' local wall-clock values. Malformed zoned values are retained and logged. This is not a blanket reinterpretation of every date.
Back up first. Rolling the migration down removes its record; it does not restore the old timestamp strings. Use ocms migrate for migration operations so the application's Go migrations run in sequence with its SQL migrations.
// MFA changes the production startup checklist
Version 0.30.0 adds authenticator-app TOTP and ten single-use recovery codes for all account roles. A password alone does not complete a sign-in when a second factor is required. Codes cannot be replayed, failed codes count toward lockout, and users manage the setup at /account/security.
Production enables the requirement by default. Before restarting an existing site, configure OCMS_MFA_KEY: at least 32 bytes, separate from the session secret. Generate a value with openssl rand -base64 32, store it in the site's environment configuration, and back it up with the database. It protects the encrypted authenticator secrets.
Users without an authenticator enroll on their next login. Sessions established without a second factor are invalidated. OCMS_REQUIRE_MFA=false explicitly opts out of the production requirement; API keys retain their separate expiry and source-network policies.
// A session has fewer routes to account takeover
Sensitive user changes now require the acting administrator's current password: passwords, email addresses, administrator-role changes, and another user's MFA reset. Content imports preserve existing administrator-role assignments when overwriting users.
DB Manager activation also asks for the password because raw SQL reaches sensitive data. Queries need no further confirmation once it is enabled, so switch it off when finished. These checks reduce what possession of an administrator's session can do on its own.
// Operations need observable outcomes
Version 0.29.0 fixes REST and scheduled-publishing webhook gaps, shutdown handling, and panic recovery inside timed requests. Editors land directly in /admin; public users get a read-only /account dashboard.
Version 0.30.0 makes deployment scripts wait for healthy instances and fail when a restarted site does not come up. An interrupted production-data sync restarts a site it stopped, and monitoring recognizes crash loops and caps restart attempts per outage.
These changes address concrete failure cases: a deployment announcing completion while the service crashes, or a failed sync leaving production stopped. Test those operational paths alongside the homepage.
// Keep the API-key correction in view
Reading the 0.29.0 notes alone gives outdated upgrade advice. That release could block production startup for an active API key outside its lifetime policy.
0.29.1 reversed the startup block. Noncompliant keys are logged and still rejected on requests, but they no longer stop the server from starting. That correction carries into 0.30.0. A running site is therefore not evidence that every stored API key is usable.
// What I would check before the restart
- A restorable database backup and a preserved MFA key.
- A readable environment file, plus the production MFA setting.
- Timestamp handling in integrations and webhook consumers.
- Authenticator enrollment, recovery codes, and account navigation.
- Actual health after deployment, followed by an editing and webhook smoke check.
The full release roundup on ocms.tech covers the changes and upgrade steps in more detail. For the source material, see the 0.29.0, 0.29.1, and 0.30.0 release notes.
