Version: 0.9.2 Last Updated: February 10, 2026 Status: Production Ready

This guide compares standalone and shared-backend deployment models to help you choose the right approach for your use case.

Standalone:

app1.example.com
├── Frontend (Next.js)
├── Backend (nSelf)
│   ├── PostgreSQL
│   ├── Hasura
│   ├── Auth
│   └── Storage
└── Monitoring

app2.example.com (separate stack)
app3.example.com (separate stack)

Shared-Backend:

Shared Infrastructure:
├── api.example.com (Hasura)
├── auth.example.com (Nhost Auth)
├── storage.example.com (MinIO)
└── db.example.com (PostgreSQL)

Applications:
├── chat.example.com → Frontend only
├── notes.example.com → Frontend only
└── tasks.example.com → Frontend only

For single apps, both approaches cost the same.

Cost savings increase with more apps.

Shared-backend has higher initial investment but faster additions.

Standalone:

• Update each backend independently
• Monitor 3 separate systems
• Backup 3 databases
• Maintain 3 sets of credentials
• Debug issues in isolation

Shared-Backend:

• Update once, affects all apps
• Single monitoring dashboard
• One database backup
• Centralized credential management
• Complex cross-app debugging

Standalone:

# Scale each app independently
docker-compose -f app1/docker-compose.yml scale hasura=3
docker-compose -f app2/docker-compose.yml scale hasura=2
docker-compose -f app3/docker-compose.yml scale hasura=1

Shared-Backend:

# Scale once for all apps
docker-compose scale hasura=5
# OR use Kubernetes HPA
kubectl scale deployment hasura --replicas=5

Standalone:

• ✅ Complete data isolation
• ✅ Independent credentials
• ✅ No cross-app vulnerabilities
• ✅ Per-app security policies
• ❌ More attack surfaces (3x backends)
• ❌ Inconsistent security updates

Shared-Backend:

• ✅ Centralized security updates
• ✅ Unified security policies
• ✅ Single audit trail
• ⚠️ Schema-based isolation (not physical)
• ⚠️ Shared credentials risk
• ⚠️ Single point of failure

Standalone:

• Dedicated resources per app
• No resource contention
• Simpler to optimize per app
• Higher total resource usage

Shared-Backend:

• Shared resources
• Potential resource contention
• More complex optimization
• Lower total resource usage
• Better cache utilization

Standalone:

App1 down: ❌ App1, ✅ App2, ✅ App3
Database issue: Only affects one app

Shared-Backend:

Backend down: ❌ All apps
Database issue: ❌ All apps (unless replicated)

Mitigation for Shared-Backend:

• High availability setup
• Database replication
• Health checks and auto-recovery
• Blue-green deployments

Situation:

• 1 app (chat platform)
• 2-person team
• Limited budget ($100/month)
• MVP stage

Recommendation: Standalone

Why:

• Simpler setup (launch faster)
• Full control
• Easy to debug
• Can migrate to shared later

Setup:

# Quick start
git clone nself-chat
cd .backend && nself start
pnpm dev

Situation:

• 3 apps (chat, notes, tasks)
• 10-person team
• Budget: $500/month
• Need SSO

Recommendation: Shared-Backend

Why:

• 23% cost savings
• Unified user management
• SSO across apps
• Centralized monitoring

Cost:

• Standalone: $192/mo
• Shared: $148/mo
• Savings: $44/mo ($528/year)

Situation:

• 10+ apps
• 100+ person organization
• Multiple teams
• Compliance requirements

Recommendation: Shared-Backend with Tenant Isolation

Why:

• Massive cost savings (41%)
• Centralized compliance
• Unified audit logs
• Easier to manage

Additional Requirements:

• Row-level security (RLS)
• Per-team namespacing
• Dedicated monitoring
• Regular security audits

Situation:

• Multiple clients
• Each needs independent app
• Full isolation required
• Per-client billing

Recommendation: Standalone per Client

Why:

• Complete isolation
• Independent billing
• Per-client customization
• No shared failure points

Considerations:

• Use automation for setup
• Centralized monitoring
• Template-based deployments

Situation:

• Need dev, staging, prod environments
• Multiple developers
• Frequent deployments

Recommendation: Standalone Environments

Why:

• Safe to break dev environment
• Independent testing
• No production impact
• Easy to reset

Setup:

# Development
NEXT_PUBLIC_ENV=development pnpm dev

# Staging (shared backend)
NEXT_PUBLIC_ENV=staging pnpm start

# Production (standalone)
NEXT_PUBLIC_ENV=production pnpm start

When to Migrate:

• Adding 2nd or 3rd app
• Need SSO
• Cost becomes concern
• Want unified management

Steps:

1. Setup Shared Backend

   # Deploy shared infrastructure
   cd shared-backend
   nself init --demo
   nself start

2. Backup Existing Data

   pg_dump app1_db > app1_backup.sql
   pg_dump app2_db > app2_backup.sql

3. Create Schemas

   CREATE SCHEMA app1;
   CREATE SCHEMA app2;

4. Migrate Data

   # Restore with schema prefix
   psql shared_db -c "SET search_path TO app1"
   psql shared_db < app1_backup.sql

5. Update App Configs

   # Point to shared backend
   NEXT_PUBLIC_GRAPHQL_URL=https://api.example.com/v1/graphql
   NEXT_PUBLIC_AUTH_URL=https://auth.example.com/v1/auth

6. Test Thoroughly

   • Verify data isolation
   • Test authentication
   • Check permissions

7. Cutover

   • Update DNS
   • Monitor closely
   • Keep old backends for rollback

Timeline: 2-3 days for 3 apps

When to Migrate:

• Security concerns
• Performance issues
• Regulatory requirements
• Team independence

Steps:

1. Export Schema Data

   pg_dump -n app1 shared_db > app1_data.sql

2. Setup New Backend

   cd app1-standalone/.backend
   nself init
   nself start

3. Import Data

   psql app1_db < app1_data.sql

4. Update App Config

   # Point to standalone backend
   NEXT_PUBLIC_GRAPHQL_URL=https://app1.example.com/v1/graphql

5. Test and Cutover

Timeline: 1-2 days per app

Some apps standalone, others shared:

Production (Standalone):
- chat.example.com → Dedicated backend

Internal Tools (Shared):
- admin.example.com
- analytics.example.com
- docs.example.com
    ↓
Shared backend at internal-api.example.com

Benefits:

• Critical apps get dedicated resources
• Internal tools share infrastructure
• Balanced cost vs performance

Do you have multiple apps?
├─ No → Use Standalone
└─ Yes → Continue

Do you need complete data isolation?
├─ Yes → Use Standalone
└─ No → Continue

Do you need SSO across apps?
├─ Yes → Use Shared-Backend
└─ No → Continue

Is cost optimization important?
├─ Yes → Use Shared-Backend
└─ No → Continue

Do you have >2 apps?
├─ Yes → Use Shared-Backend
└─ No → Use Standalone

• ✅ Single application
• ✅ Independent teams
• ✅ Maximum isolation required
• ✅ Simple setup preferred
• ✅ Each app has unique requirements

• ✅ Multiple applications (2+)
• ✅ Need SSO across apps
• ✅ Cost optimization important
• ✅ Unified user management
• ✅ Centralized monitoring
• ✅ Shared data requirements

• ✅ Fastest time to market
• ✅ Can always migrate when scaling
• ✅ Lower initial complexity
• ✅ Learn before optimizing

• Standalone Deployment Guide
• Shared-Backend Deployment Guide
• Subdomain Routing Guide
• Environment Variables Guide

Still Unsure?

1. Start with Standalone for MVP
2. Add 2nd app with Standalone
3. When adding 3rd app, consider migrating to Shared-Backend
4. The migration path is well-documented

Need Help Deciding?

• GitHub Discussions: https://github.com/yourusername/nself-chat/discussions
• Community Discord: https://discord.gg/nself