Production Deployment Guide
Relevant source files
The following files were used as context for generating this wiki page:
This guide outlines the professional deployment workflow for the Monarch Property Management platform. It encompasses backend database hardening using Supabase, frontend synchronization, environment variable security, and post-deployment validation procedures. The primary objective is to transition the system from development to a secure, high-performance production state.
The deployment process is divided into distinct phases: backend migration and security enforcement, frontend build and environment configuration, and comprehensive integration testing to ensure Role-Based Access Control (RBAC) and Row Level Security (RLS) are functioning as intended.
Sources: DEPLOYMENT_GUIDE.md:1-25
Deployment Architecture and Workflow
The deployment workflow follows a linear path from backend infrastructure hardening to frontend delivery and final automated verification.
Deployment Process Flow
The following diagram illustrates the sequential stages of a production release, starting with database backups and ending with performance validation.
A flowchart representing the end-to-end deployment lifecycle.
Sources: DEPLOYMENT_GUIDE.md:38-120, scripts/performance-validation.sh:1-30
Phase 1: Backend Security Hardening
The backend deployment focuses on "Hardening," which involves implementing performance indexes, SECURITY DEFINER functions, and strict RLS policies to protect data.
Key Backend Components
| Component | Description | Quantity/Target |
|---|---|---|
| Performance Indexes | B-tree indexes for optimized query execution on IDs and status columns | 8 Indexes |
| Helper Functions | SECURITY DEFINER functions for auth and room access | 5 Functions |
| RLS Policies | Row-level security to prevent unauthorized data access | 15+ Policies |
| RLS-Enabled Tables | Core tables including profiles, vendor_bids, and leases | 8+ Tables |
Sources: DEPLOYMENT_GUIDE.md:10-20, scripts/verify_deployment.sql:15-100
Security Verification Logic
Post-migration, the system must verify that no policies are granted to the public role and that specific security functions exist with the correct permissions.
A sequence diagram showing the automated verification of database security settings.
Sources: scripts/verify_deployment.sql:10-140
Phase 2: Frontend Synchronization
The frontend deployment requires merging role enforcement logic and configuring environment variables that communicate with the Supabase API.
Environment Variable Requirements
Critical variables must be set in the deployment environment (e.g., Vercel or Netlify). Variables prefixed with VITE_ are exposed to the client, while others remain server-side only.
| Variable | Scope | Requirement |
|---|---|---|
VITE_SUPABASE_URL | Public | Project API Endpoint |
VITE_SUPABASE_PUBLISHABLE_KEY | Public | Anon/Public Key |
SUPABASE_SERVICE_ROLE_KEY | Private | NEVER expose to client bundle |
Sources: DEPLOYMENT_GUIDE.md:95-110
Build and Optimization
The frontend utilizes Vite for building a production-ready bundle. The deployment involves:
- Dependency Installation:
npm install - Production Build:
npm run build - Resource Preloading: The
index.htmlfile is configured to preconnect to the Supabase URL and preload critical hero images (hero-optimized.webp) for Largest Contentful Paint (LCP) optimization.
Sources: DEPLOYMENT_GUIDE.md:115-130, index.html:1-70
Phase 3: Integration and Performance Validation
The final stage involves validating that the application meets the specific performance targets and security requirements defined in the validation scripts.
Core Web Vitals Targets
The performance-validation.sh script runs Lighthouse audits against the production environment with the following targets:
| Metric | Target Score / Value |
|---|---|
| Performance | 90+ |
| Accessibility | 100 |
| Best Practices | 100 |
| SEO | 90 |
| FCP (First Contentful Paint) | < 2.0s |
| CLS (Cumulative Layout Shift) | < 0.1 |
Sources: scripts/performance-validation.sh:65-80
Automated Performance Testing Logic
Flowchart of the shell script responsible for performance regression testing.
Sources: scripts/performance-validation.sh:85-150
Rollback Procedures
In the event of a deployment failure, the following strategies are implemented to restore service.
Backend Rollback
If migrations fail or cause RLS blocks, the primary recovery method is restoring the database from the pre-deployment backup (e.g., pre-hardening-backup-2025-10-19). Alternatively, a manual rollback script can be used to drop specific policies and functions.
Sources: DEPLOYMENT_GUIDE.md:195-215
Frontend Rollback
Frontend failures are addressed via Git:
- Option 1: Revert the merge commit using
git revert HEADand push to main. - Option 2: Manually redeploy a previously known stable commit hash using the hosting platform's dashboard.
Sources: DEPLOYMENT_GUIDE.md:217-225
This production deployment workflow ensures that the Monarch Property Management system remains secure, performant, and reliable through rigorous verification and clear recovery paths.