All checks were successful
Container CVE Scan (development) / Scan backend/frontend images for CVEs (push) Successful in 2m40s
PostgreSQL Compatibility Matrix / PG14 smoke (push) Successful in 8s
PostgreSQL Compatibility Matrix / PG15 smoke (push) Successful in 7s
PostgreSQL Compatibility Matrix / PG16 smoke (push) Successful in 7s
PostgreSQL Compatibility Matrix / PG17 smoke (push) Successful in 7s
PostgreSQL Compatibility Matrix / PG18 smoke (push) Successful in 8s
Proxy Profile Validation / validate (push) Successful in 3s
Introduced a secure, repeatable production proxy profile for reverse proxy and HTTPS deployment, including NGINX configuration, environment variables, and CORS guidance. Added CI workflow for static validation of proxy guardrails and detailed documentation to ensure best practices in deployment.
79 lines
2.0 KiB
Markdown
79 lines
2.0 KiB
Markdown
# Production Proxy Profile (HTTPS)
|
|
|
|
This profile defines a secure and repeatable NexaPG deployment behind a reverse proxy.
|
|
|
|
## Included Profile Files
|
|
|
|
- `ops/profiles/prod/.env.production.example`
|
|
- `ops/profiles/prod/nginx/nexapg.conf`
|
|
|
|
## CORS Recommendations by Environment
|
|
|
|
| Environment | Recommended `CORS_ORIGINS` | Notes |
|
|
|---|---|---|
|
|
| `dev` | `*` or local explicit origins | `*` is acceptable only for local/dev usage. |
|
|
| `staging` | Exact staging UI origins | Example: `https://staging-monitor.example.com` |
|
|
| `prod` | Exact production UI origin(s) only | No wildcard; use comma-separated HTTPS origins if needed. |
|
|
|
|
Examples:
|
|
|
|
```env
|
|
# dev only
|
|
CORS_ORIGINS=*
|
|
|
|
# staging
|
|
CORS_ORIGINS=https://staging-monitor.example.com
|
|
|
|
# prod
|
|
CORS_ORIGINS=https://monitor.example.com
|
|
```
|
|
|
|
## Reverse Proxy Requirements
|
|
|
|
For stable auth, CORS, and request context handling, forward these headers to backend:
|
|
|
|
- `Host`
|
|
- `X-Real-IP`
|
|
- `X-Forwarded-For`
|
|
- `X-Forwarded-Proto`
|
|
- `X-Forwarded-Host`
|
|
- `X-Forwarded-Port`
|
|
|
|
Also forward API paths:
|
|
|
|
- `/api/` -> backend service (`:8000`)
|
|
|
|
## Mixed-Content Prevention
|
|
|
|
NexaPG frontend is designed to avoid mixed-content in HTTPS mode:
|
|
|
|
- Build/runtime default API base is relative (`/api/v1`)
|
|
- `frontend/src/api.js` upgrades `http` API URL to `https` when page runs on HTTPS
|
|
|
|
Recommended production setting:
|
|
|
|
```env
|
|
VITE_API_URL=/api/v1
|
|
```
|
|
|
|
## Validation Checklist
|
|
|
|
1. Open app over HTTPS and verify:
|
|
- login request is `https://.../api/v1/auth/login`
|
|
- no browser mixed-content errors in console
|
|
2. Verify CORS behavior:
|
|
- allowed origin works
|
|
- unknown origin is blocked
|
|
3. Verify backend receives forwarded protocol:
|
|
- proxied responses succeed with no redirect/proto issues
|
|
|
|
## CI Validation
|
|
|
|
`Proxy Profile Validation` workflow runs static guardrail checks:
|
|
|
|
- relative `VITE_API_URL` default
|
|
- required API proxy path in frontend NGINX config
|
|
- required forwarded headers
|
|
- HTTPS mixed-content guard in frontend API resolver
|
|
- production profile forbids wildcard CORS
|