103 lines
3.5 KiB
Markdown
103 lines
3.5 KiB
Markdown
# Production deployment notes
|
|
|
|
## Gitea Actions
|
|
This repo includes `.gitea/workflows/ci-deploy.yml` for:
|
|
- backend build
|
|
- backend tests
|
|
- frontend tests
|
|
- frontend production build
|
|
- deployment to Ubuntu after successful tests on `main`
|
|
|
|
### Required secrets in Gitea
|
|
- `PROD_HOST`
|
|
- `PROD_USER`
|
|
- `PROD_SSH_KEY`
|
|
|
|
## Ubuntu server setup
|
|
Recommended app path:
|
|
- `/opt/job-tracker/app`
|
|
|
|
Persistent runtime secrets path:
|
|
- `/opt/job-tracker/shared/.env`
|
|
|
|
Requirements:
|
|
- Docker Engine
|
|
- Docker Compose plugin
|
|
- reverse proxy in front (Nginx, Caddy, or Traefik)
|
|
- shared env file present on server in `/opt/job-tracker/shared/.env`
|
|
- network connectivity from the backend container to your `mariadb` container/service
|
|
|
|
The deploy script will automatically create a symlink from:
|
|
- `/opt/job-tracker/shared/.env`
|
|
|
|
to:
|
|
- `/opt/job-tracker/app/.env`
|
|
|
|
This keeps secrets outside the uploaded repo checkout so they are not wiped by CI deploys.
|
|
|
|
### Frontend API base URL
|
|
The production frontend already proxies `/api` to the backend container via Nginx.
|
|
|
|
Recommended default:
|
|
- leave `REACT_APP_API_BASE_URL` unset/empty in production
|
|
|
|
Only set `REACT_APP_API_BASE_URL` if the UI must call a different external API origin on purpose.
|
|
|
|
## Example production `.env`
|
|
```env
|
|
DATABASE_PROVIDER=mariadb
|
|
JOBTRACKER_CONNECTION_STRING=server=mariadb;port=3306;database=jobtracker;user=jobtracker;password=REPLACE_ME
|
|
AUTH_JWT_KEY=replace_with_long_random_secret
|
|
AUTH_ADMIN_EMAIL=you@example.com
|
|
AUTH_ADMIN_PASSWORD=replace_with_strong_password
|
|
APP_PUBLIC_BASE_URL=https://your-domain.example
|
|
AI_SERVICE_BASE_URL=http://ai-service:8001
|
|
OLLAMA_BASE_URL=http://ollama:11434
|
|
OLLAMA_MODEL=qwen2.5:7b
|
|
EMAIL_FOLLOWUPREMINDERS_ENABLED=true
|
|
EMAIL_FOLLOWUPREMINDERS_UPCOMINGDAYS=2
|
|
# Optional backward-compatible alias if older config still references the previous name:
|
|
SUMMARIZER_BASE_URL=http://ai-service:8001
|
|
```
|
|
|
|
## Database recommendation
|
|
For production, yes — use a real database.
|
|
|
|
### Recommended direction
|
|
Short term:
|
|
- SQLite is acceptable for a single-user or very small deployment
|
|
- keep backups and volume persistence
|
|
|
|
Better production choice:
|
|
- MariaDB or PostgreSQL
|
|
|
|
### My recommendation
|
|
- **PostgreSQL** if you want the best long-term maintainability and fewer edge cases
|
|
- **MariaDB** is also fine if that is what you already know or host elsewhere
|
|
|
|
If you stay on SQLite:
|
|
- okay for small personal use
|
|
- not ideal for concurrent writes, larger scale, or operational robustness
|
|
|
|
## Practical recommendation for this project
|
|
If this app is going to be a real production service on Ubuntu:
|
|
- move to PostgreSQL first if possible
|
|
- MariaDB is still a reasonable option if preferred
|
|
|
|
## Deployment flow
|
|
1. push to `main`
|
|
2. Gitea Actions runs tests
|
|
3. if green, workflow uploads repo to server
|
|
4. `deploy/deploy.sh` links `/opt/job-tracker/shared/.env` into the repo checkout, then runs `docker compose build && docker compose up -d`
|
|
5. if `OLLAMA_MODEL` is set, the deploy script waits for Ollama, pulls the configured model if missing, then restarts `ai-service` so hybrid CV classification can use it
|
|
6. workflow checks service status after deployment
|
|
|
|
## Post-deploy verification you should also do manually the first time
|
|
- confirm reverse proxy routes to the frontend correctly
|
|
- confirm API auth/login works with production config
|
|
- confirm backend can connect to MariaDB
|
|
- confirm AI service container is reachable from backend
|
|
- confirm reminder and admin/system pages load
|
|
- verify follow-up reminder emails are enabled only when intended and that links open the correct job/tab
|
|
hat links open the correct job/tab
|