Skip to content

ROADMAP.md

Latest commit

 

History

History
94 lines (60 loc) · 2.86 KB

ROADMAP.md

File metadata and controls

94 lines (60 loc) · 2.86 KB

1. VPS & Domain Setup

  • Buy VPS (Ubuntu/Debian is common).
  • Point domain → VPS IP using your registrar’s DNS (A record for example.com, maybe chat.example.com).
  • Set up SSH access with keys, disable password login.
  • Install basic packages (docker, docker-compose, git, nginx, ufw).

2. Containerize Your Stack

You already use Docker for RabbitMQ, so extend it:

  • Backend (.NET + Postgres)

    • Multi-stage Dockerfile (build → runtime).
    • Postgres runs in its own container with volume for persistence.

  • Frontend (React + Vite)

    • Dockerfile that builds static assets → serves with nginx (or Caddy).

  • RabbitMQ

    • Official RabbitMQ container with exposed port.

  • Create a docker-compose.yml that orchestrates backend + db + rabbitmq + frontend.

3. Reverse Proxy & SSL

  • Use nginx or Caddy in front:

    • Proxy traffic to frontend (static files) + backend API.
    • Terminate SSL with Let’s Encrypt (e.g., certbot or Caddy auto-TLS).

  • Example:

    • chat.example.com → frontend (nginx serving React build).
    • chat.example.com/api → backend container.

4. CI/CD Pipeline

Pick GitHub Actions (most common):

  • On Push to main branch:

    1. Build backend & frontend Docker images.
    2. Run unit tests.
    3. Push images to registry (Docker Hub or GHCR).
    4. SSH into VPS & pull latest images.
    5. docker-compose down && docker-compose up -d.

  • You can do this via:

    • GitHub Actions → appleboy/ssh-action for remote deploy.
    • Or use self-hosted runner directly on the VPS (pulls code & rebuilds).

5. Database & State

  • Keep Postgres data in a named Docker volume or bind mount.
  • Backup strategy: pg_dump → S3/other storage.
  • RabbitMQ queues don’t need persistence unless you want durable message logs (enable volumes if yes).

6. Monitoring & Scaling (Optional, but “good stuff”)

  • Logs: use Docker logging driver → journald or json-file, later maybe ELK stack.
  • Healthchecks: add HEALTHCHECK in Dockerfiles + configure in docker-compose.
  • Metrics: Prometheus + Grafana if you want dashboards.
  • Scaling: initially all in one VPS → later can move to Kubernetes or managed services.

7. Developer UX

  • .env file with configs (db, rabbitmq, secrets).
  • Separate dev compose file (with hot reload) vs prod compose (optimized builds).
  • Pre-commit hooks, lint, and test jobs in CI.

👉 So the “flow” will look like this:

  1. Push code → GitHub Actions triggers.
  2. Build & test images → Push to registry.
  3. Deploy step updates VPS containers.
  4. Nginx/Caddy routes requests under your domain → app is live.

Do you want me to draft a minimal docker-compose + GitHub Actions workflow file that wires frontend + backend + postgres + rabbitmq together, so you have a working baseline?