Operations — deployment
What it is
How ManpowerIQ is run today, and how it is intended to be hosted. Current reality: local serve. Hosted deployment is planned, not built.
Current — local serve
The system runs locally via docker-compose + dotnet run + npm run dev — see Local run & reset. That is the supported way to run it today: there is no production deployment in place, no CI/CD deploy pipeline, and no infrastructure-as-code in the repository.
Planned — EC2 / nginx
The intended hosting is an AWS EC2 instance behind nginx (reverse proxy serving the built web app and proxying the API). This is planned, not done:
- No deploy scripts, systemd units, or nginx config are committed.
- No environment provisioning is automated.
- The EC2/nginx target is a roadmap intention, not a shipped capability.
When it is built, the shape is expected to be: the .NET API published and run as a service, the web app built (npm run build) and served as static files via nginx, nginx terminating TLS and proxying /api to the API, and PostgreSQL as a managed or self-hosted instance with the two-connection (owner / RLS-bound) split preserved (see Multi-tenancy).
Gotchas / constraints
- Don't treat EC2/nginx as live — it's a target, not a deployment. Anything claiming the app is "deployed" is aspirational.
- The two-connection-string split must survive to production — runtime must use the RLS-bound role, never the owner.
IsDevelopment()-gated diagnostics must be removed/restricted before any real deployment — see F9 / PB-114.- No migrate-on-startup — a deployment process must run
dotnet ef database updateas an explicit step.
Build status
Planned — local serve is current; EC2/nginx hosting is intended but not built. Documented honestly as planned.
Related
- Local run & reset · Monitoring · Migrations
- Multi-tenancy — the connection-string split to preserve.