Analyze current differences between development and production environments
and provide three options for improving parity:
1. Conservative: Minimal changes, maximum benefit
- 2 replicas for critical services
- Resource limits at 50% of prod
- Specific CORS origins
- Resource impact: +30% RAM
2. High Parity: Maximum similarity
- Match all prod replica counts
- Production resource limits
- Enable SSL and monitoring
- Resource impact: +200% RAM
3. Hybrid: Balanced approach
- 2 replicas for stateful services
- Resources at 60% of prod
- Production configs with dev features
- Resource impact: +100% RAM
Recommendation: Start with Option 1 for best cost/benefit ratio.
This commit adds complete documentation and tooling for migrating from
local development (Kind/Colima on macOS) to production deployment
(MicroK8s on Ubuntu VPS at Clouding.io).
Documentation added:
- K8S-MIGRATION-GUIDE.md: Comprehensive step-by-step migration guide
covering all phases from VPS setup to post-deployment operations
- MIGRATION-CHECKLIST.md: Quick reference checklist for migration tasks
- MIGRATION-SUMMARY.md: High-level overview and key changes summary
Configuration updates:
- Added storage-patch.yaml for MicroK8s storage class compatibility
(changes from 'standard' to 'microk8s-hostpath')
- Updated prod/kustomization.yaml to include storage patch
Helper scripts:
- deploy-production.sh: Interactive deployment script with validation
- tag-and-push-images.sh: Automated image tagging and registry push
- backup-databases.sh: Database backup script for production
Key differences addressed:
- Ingress: MicroK8s addon vs custom NGINX
- Storage: MicroK8s hostpath vs Kind standard storage
- Registry: Container registry configuration for production
- SSL: Let's Encrypt production certificates
- Domains: Real domain configuration vs localhost
- Resources: Production-grade resource limits and scaling
The migration guide covers:
- VPS setup and MicroK8s installation
- Configuration adaptations required
- Container registry setup options
- SSL certificate configuration
- Monitoring and backup setup
- Troubleshooting common issues
- Security hardening checklist
- Rollback procedures
All existing Kubernetes manifests remain unchanged and compatible.
Clear auth store when exiting demo session to prevent unauthorized page redirect.
## Problem
When users clicked "Salir" (Exit) from the demo session, they were redirected to the unauthorized page (`/unauthorized`) instead of the demo landing page (`/demo`).
## Root Cause
The `handleExpiration()` function in DemoBanner.tsx was clearing localStorage and navigating to `/demo`, but was NOT clearing the auth store. This created an inconsistent state:
- `isDemoMode = false` (localStorage cleared)
- `demoSessionId = null` (localStorage cleared)
- `isAuthenticated = true` (auth store NOT cleared - still has demo user)
The `useHasAccess()` hook checks:
```typescript
return isAuthenticated || (isDemoMode && !!demoSessionId);
```
After clearing localStorage but not auth:
- `isAuthenticated = true` but the demo session is invalid
- `isDemoMode = false` and `demoSessionId = null`
- Result: `useHasAccess()` returns `false`
When navigating to `/demo`, the ProtectedRoute checked access and found it was `false`, redirecting to `/unauthorized`.
## Solution
Call `logout()` on the auth store before navigating to clear the demo user session completely. This ensures:
- Auth store is cleared (`isAuthenticated = false`)
- User is properly logged out from demo session
- Navigation to `/demo` succeeds without authentication check
## Additional Improvements
- Also clear `virtual_tenant_id` and `subscription_tier` from localStorage
- Updated comment to clarify navigation intent
## Files Changed
- frontend/src/components/layout/DemoBanner/DemoBanner.tsx:73-74
- Added auth store logout before navigation
- Added clearing of virtual_tenant_id and subscription_tier
- Updated comment for clarity
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
