AI AI Workforce OS v1.0.0

Deployment

Running AI Workforce OS in production: scaling, monitoring, backups, and release process.

System/IT AdministratorsDevOps

Overview#

This page covers what changes when you move from a working installation (see Installation) to a production deployment serving real employees.

Purpose#

Give System/IT Administrators a realistic picture of production readiness, including gaps you should plan around before go-live.

Prerequisites#

  • A working installation following the steps in Installation.
  • A process for applying database migrations safely (backup first).

Step-by-Step Instructions#

Production checklist#

  1. Confirm SSL/DNS is in place and COOKIE_SECURE=true.
  2. Set strong, unique values for JWT_ACCESS_SECRET and ENCRYPTION_KEY and store them in a secrets manager, not in plain files.
  3. Configure MFA and/or SSO before onboarding real users — see Security.
  4. Decide on and test your database backup and restore process (see the warning below).
  5. Configure push-notification credentials if you plan to use them — see Mobile App.
  6. Review and set the API rate-limit and lockout thresholds appropriate for your organization size.

Screens Involved#

📷
[Screenshot: Deployment pipeline / CI logs (external to the application UI)]

Expected Results#

A production deployment that is reachable over HTTPS, backed by a database you can back up and restore, with authentication hardened via MFA/SSO.

Not Available in This Release#

🚫
Not currently available
  • No official Kubernetes manifests. Container images publish to a registry via CI, but nothing in the repository deploys them — you own that step.
  • No built-in alerting is wired up for infrastructure issues — connect your own monitoring stack.
  • A tested, documented backup-and-restore drill for the production database has not been performed by the product team as of this release. Treat backups as your responsibility to design and test.

Common Mistakes#

  • Going live without ever testing a database restore from backup.
  • Assuming horizontal scaling "just works" without first confirming Redis and PostgreSQL are sized for the additional load.
  • Leaving default rate-limit and lockout settings unreviewed for a large organization, causing legitimate users to be locked out during peak login times (e.g. shift start).

Troubleshooting#

I need to scale to more users.#

Scale the api and web containers horizontally behind a load balancer. Both PostgreSQL and Redis should be sized and monitored independently, since both are shared dependencies across all application instances.

A release introduced a database migration — how do I apply it safely?#

Take a database backup, apply the migration in a maintenance window, then restart the API containers. Always test migrations in a staging environment first.

InstallationSecurityTroubleshooting

FAQ#

Does the product include monitoring or alerting?

No built-in alerting ships with the product. You are expected to connect your own monitoring/observability stack to the containers and database.

Is there a tested disaster-recovery process?

As of this release, a live database backup-and-restore drill has not been performed by the product team. Design, document, and test your own backup and restore process before relying on it.

How are new versions released?

Container images are published via CI on release. See Release Notes for what changed in each version.

Best Practices#

  • Treat backup/restore testing as a launch blocker, not a nice-to-have, given it is not pre-validated by the product itself.
  • Roll out to a small pilot group before opening the system to your full workforce.
  • Review Release Notes before upgrading a production environment.