Last Updated: 2025-12-29 Version: 1.0.0-beta2 Maintainer: DevOps Team
The Refactor Platform backend uses GitHub Actions for continuous integration, release builds, and production deployment. This document provides a comprehensive overview of the CI/CD infrastructure.
Quick Stats:
- 8 GitHub Actions Workflows (CI, Release, Deploy, PR Preview x5)
- Docker-based Deployment to GitHub Container Registry (GHCR)
- Production Platform: DigitalOcean (accessed via Tailscale VPN)
- Preview Platform: Raspberry Pi 5 (ARM64, accessed via Tailscale VPN)
- Container Orchestration: Docker Compose with Nginx reverse proxy
- Database: PostgreSQL with SeaORM migrations
- GitHub Actions Workflows
- PR Preview Environments
- Docker Infrastructure
- Database Migrations
- Release Process
- Production Deployment
- Security & Secrets
- Quick Reference
- Gap Analysis & Future Improvements
File: .github/workflows/build-test-push.yml
Triggers: Push to main, Pull requests to main, Manual dispatch
Documentation: workflows/build-test-push.md
Jobs:
- Lint - Clippy (zero warnings) + rustfmt check
- Test - Build all targets + run test suite
- Docker - Build and push images to GHCR (only if lint and test pass)
Image Tags:
ghcr.io/refactor-group/refactor-platform-rs/{branch}:latestghcr.io/refactor-group/refactor-platform-rs/{branch}:{git-sha}
Key Features:
- ✅ Quality gates (lint/test before docker build)
- ✅ Rust dependency caching (Swatinem/rust-cache)
- ✅ Docker layer caching (GitHub Actions cache)
- ✅ Build provenance attestations (main branch only)
File: .github/workflows/build_and_push_production_images.yml
Triggers: GitHub releases (type: released), Manual dispatch
Documentation: workflows/production-images.md
Multi-Architecture Builds:
- linux/amd64
- linux/arm64
Image Tag: ghcr.io/refactor-group/refactor-platform-rs:stable
Key Features:
- ✅ Runs full test suite before building
- ✅ Multi-platform builds for broader deployment options
- ✅ Tagged as "stable" for production use
- ✅ Build provenance attestations
File: .github/workflows/deploy_to_do.yml
Triggers: Manual dispatch only
Documentation: workflows/deploy-to-do.md
Deployment Flow:
- Establish Tailscale VPN connection to DigitalOcean server
- Generate
.envfile from GitHub secrets/variables - Download docker-compose.yaml and nginx configs
- Stop systemd service (
refactor-platform.service) - Pull latest Docker images from GHCR
- Start systemd service
- Verify deployment (health checks, container status)
Key Features:
- ✅ Secure VPN-based deployment (Tailscale)
- ✅ Systemd service management
- ✅ Health checks and verification
- ✅ Deploys both backend and frontend together
⚠️ Manual trigger only (no auto-deploy)
Files:
.github/workflows/dispatch-pr-preview.yml(backend manual dispatch).github/workflows/ci-deploy-pr-preview.yml(reusable workflow)
Triggers: Manual workflow_dispatch only — previews are not created automatically on PR events.
Documentation: pr-preview-environments.md
Files:
.github/workflows/cleanup-pr-preview-backend.yml(trigger).github/workflows/cleanup-pr-preview.yml(reusable workflow)
Triggers: Pull request closed/merged
Deployment Flow:
- User manually triggers "Deploy PR Preview (Manual Select)" workflow
- Selects backend and frontend commits from dropdowns (or enters SHA overrides)
- Reusable workflow builds native ARM64 images on Neo runner
- Deploys to Raspberry Pi 5 via Tailscale VPN
- Posts preview URLs to PR comment
- Cleanup runs automatically on PR close/merge
Key Features:
- ✅ Isolated full-stack environments per PR
- ✅ Manual dispatch — deploy only when you need a preview
- ✅ Unique port allocation (base_port + PR#)
- ✅ Native ARM64 builds (no emulation)
- ✅ Automatic cleanup with volume retention policies
- ✅ Cross-repository workflow coordination
Port Allocation:
- Frontend: 3000 + PR#
- Backend: 4000 + PR#
- Postgres: 5432 + PR#
Frontend Integration:
The frontend repository has its own manual dispatch workflow (dispatch-pr-preview-frontend.yml) that calls the same reusable workflow with repo_type: 'frontend'. Cleanup is handled by cleanup-pr-preview-frontend.yml.
File: Dockerfile
Documentation: docker/dockerfile-guide.md
Stages:
- Chef (Planner) - Uses cargo-chef to analyze dependencies
- Builder - Compiles dependencies and application separately for optimal caching
- Runtime - Minimal Debian Bullseye Slim with only necessary binaries
Compiled Binaries:
refactor_platform_rs- Main API servermigration- Database migration tool (migrationctl)
Security Features:
- Non-root user (appuser, UID 1001)
- Minimal runtime dependencies
- Only essential files copied to runtime image
Files:
docker-compose.yaml- Production configurationdocker-compose.dev-staging.yaml- Dev/staging overlay (adds PostgreSQL container)
Documentation: docker/docker-compose-guide.md
Services:
| Service | Purpose | Restart Policy |
|---|---|---|
| nginx | Reverse proxy (ports 80, 443) | unless-stopped |
| migrator | Runs database migrations once | no (exits after completion) |
| rust-app | Backend API (port 4000) | unless-stopped |
| nextjs-app | Frontend (port 3000) | unless-stopped |
| postgres | Database (dev/staging only) | unless-stopped |
Network: backend_network (bridge mode)
File: entrypoint.sh
Documentation: docker/entrypoint-guide.md
Execution Modes (via ROLE environment variable):
ROLE=migrator- Runs database migrations via SeaORM CLIROLE=app- Runs the Rust API server
Features:
- Environment variable validation
- Comprehensive logging
- Configuration defaults for common settings
Framework: SeaORM Migration CLI Total Migrations: 15 (1 base SQL + 14 SeaORM migrations) Documentation: database/migration-workflow.md
Migration Execution:
- Automatically runs in
migratorcontainer before app startup - Uses custom PostgreSQL schema:
refactor_platform - Database user:
refactor
When creating PostgreSQL types with create_type(), you MUST immediately follow with:
ALTER TYPE refactor_platform.<type_name> OWNER TO refactor;This prevents "must be owner of type" errors in subsequent migrations. See: database/postgresql-type-ownership.md
Local Development Scripts:
scripts/rebuild_db.sh- Local PostgreSQL setupscripts/rebuild_db_container.sh- Containerized setup
Current Status: Manual process Documentation: releases/release-workflow.md
Release Steps:
- Version Bump - Manually edit
Cargo.toml(all workspace members at same version) - Release Notes - Create markdown file (e.g.,
RELEASE_NOTES_1.0.0-beta1.md) - GitHub Release - Create release through GitHub UI
- Triggers
build_and_push_production_images.yml - Builds multi-arch images tagged as "stable"
- Triggers
- Deployment - Manually trigger
deploy_to_do.ymlworkflow
Frontend Coordination:
- Frontend repo:
../refactor-platform-fe - Both currently at version 1.0.0-beta2
- Versions appear to be manually synchronized
- Both deployed together in same workflow
See: releases/frontend-backend-coordination.md
Platform: DigitalOcean Droplet
Access: Tailscale VPN (private network)
Service Management: systemd (refactor-platform.service)
Reverse Proxy: Nginx with Let's Encrypt SSL
Domains:
- myrefactor.com (primary)
- refactor.engineer (redirects to primary)
SSL Certificates:
- Let's Encrypt certificates
- Auto-renewal script:
nginx/scripts/renew-certs.sh
Database:
- PostgreSQL (appears to be DigitalOcean managed service)
- SSL/TLS connection with certificate verification
Systemd Commands:
# View status
systemctl status refactor-platform.service
# View logs
journalctl -xeu refactor-platform.service -f
# Restart service
systemctl restart refactor-platform.serviceDocumentation: security/secrets-management.md
GitHub Secrets Required: (30+ secrets and variables)
Categories:
- DigitalOcean: SSH keys, host keys, server details
- Tailscale: OAuth client credentials
- Database: User, password, SSL certificate
- Container Registry: GHCR credentials
- External Services: TipTap, Resend API keys
VPN Access:
- Tailscale VPN provides secure access to production server
- OAuth-based authentication
- Documentation: security/tailscale-vpn.md
Branch Build:
# Automatically triggered on:
git push origin <branch-name>
# Or manual trigger via GitHub Actions UICreate Release:
- Go to GitHub > Releases
- Click "Create new release"
- Choose tag (e.g.,
1.0.0-beta3) - Write release notes
- Publish release → Triggers production image build
Deploy to Production:
- Go to GitHub Actions
- Select "Deploy to DigitalOcean" workflow
- Click "Run workflow"
- Optionally enable SSH debugging
- Confirm and run
Build Locally:
docker build -t refactor-backend .Run Locally (app mode):
docker run --rm --env-file .env -p 4000:4000 refactor-backendRun Locally (migrator mode):
docker run --rm -e ROLE=migrator -e DATABASE_URL=... refactor-backendDocker Compose (Dev/Staging):
# Start with local PostgreSQL
docker compose -f docker-compose.yaml -f docker-compose.dev-staging.yaml up
# View logs
docker compose logs -f rust-app
# Stop all services
docker compose down
# Remove volumes too
docker compose down -vCreate New Migration:
cd migration
sea-orm-cli migrate generate <migration_name>Run Migrations (Local):
DATABASE_URL=postgres://refactor:password@localhost:5432/refactor_platform \
sea-orm-cli migrate up -s refactor_platformRefresh Database (Local):
./scripts/rebuild_db.shDocumentation Gaps: ✅ Being addressed in this PR
Infrastructure Gaps:
⚠️ No automated semantic versioning⚠️ No automated changelog generation⚠️ No security scanning (cargo-audit, Dependabot)⚠️ No test coverage reporting⚠️ No deployment notifications⚠️ No staging environment⚠️ No automated rollback mechanism⚠️ Manual production deployment (human error risk)
See Complete Analysis: gap-analysis.md
High Priority (Next):
- Add Dependabot for automated dependency updates
- Add cargo-audit security scanning to CI
- Implement deployment notifications (Slack/email)
- Create deployment checklists
- Add test coverage reporting
Medium Priority:
- Implement semantic versioning automation
- Add staging environment
- Automated changelog generation
- Infrastructure as code (Terraform)
See Complete Roadmap: future-improvements.md
- Workflow Documentation - Detailed workflow analysis
- Docker Documentation - Container and orchestration guides
- Database Documentation - Migration and setup guides
- Release Documentation - Release process and coordination
- Security Documentation - Secrets, VPN, and SSL management
- Diagrams - Visual representations of CI/CD flows
- Templates - Checklists and runbook templates
This documentation should be updated when:
- New workflows are added or existing ones significantly modified
- Docker infrastructure changes (new services, configuration changes)
- Database migration process changes
- Release process changes
- New secrets or environment variables are added
- Production infrastructure changes
Documentation Owner: DevOps Team Review Frequency: Quarterly or with major changes Last Review: 2025-12-29