qRun vs Self-Hosting: Choosing the Right Deployment

Should you deploy your qqq application on qRun's managed platform or self-host? We break down the tradeoffs to help you make the right choice.

qRun vs Self-Hosting: Choosing the Right Deployment

One of qqq's core principles is no lock-in. The same application runs identically on qRun's managed platform or your own infrastructure. Your choice should be based purely on operational preferences, not technical constraints.

The code you write, the metadata you define, the business logic you implement - all of it works the same whether you deploy to qRun or your own Kubernetes cluster.

The Decision Framework

Before diving into specifics, here's a quick decision tree:

Choose qRun if:

  • You want to focus on building, not operating
  • You're a small team without dedicated DevOps
  • You need to get to production fast
  • You want managed scaling and updates

Choose Self-Hosting if:

  • You have strict data residency requirements
  • You have existing infrastructure you want to use
  • You need custom network configurations
  • You have a DevOps team ready to operate

qRun: Managed Platform

qRun handles everything from deployment to monitoring. Here's what you get:

bash
# Deploy to qRun
qrun deploy --app my-app --env production
 
# That's it. qRun handles:
# - Container building
# - Database provisioning
# - SSL certificates
# - Load balancing
# - Auto-scaling
# - Monitoring
# - Backups

What's Included

Infrastructure Management

  • Automatic container orchestration
  • Database provisioning (PostgreSQL, MySQL)
  • Redis for caching and sessions
  • Object storage for files
  • CDN for static assets

Operations

  • Zero-downtime deployments
  • Automatic scaling based on load
  • Daily backups with point-in-time recovery
  • 24/7 monitoring and alerting
  • Log aggregation and search

Security

  • Managed SSL certificates
  • DDoS protection
  • Regular security patches
  • SOC 2 compliance
  • Data encryption at rest and in transit

qRun Pricing

| Tier | Price | Resources | Best For | |------|-------|-----------|----------| | Free | $0/mo | 512MB RAM, shared DB | Development, prototypes | | Startup | $49/mo | 2GB RAM, dedicated DB | Small production apps | | Pro | $199/mo | 8GB RAM, HA database | Growing applications | | Enterprise | Custom | Custom sizing, SLA | Large-scale deployments |

Self-Hosting: Full Control

Self-hosting means running qqq on your own infrastructure. You have complete control over every aspect.

Deployment Options

Docker Compose (simplest)

yaml
# docker-compose.yml
version: '3.8'
services:
  app:
    image: qrunio/qqq-runtime:latest
    environment:
      - DATABASE_URL=postgres://...
      - QQQ_APP_PATH=/app
    volumes:
      - ./my-app:/app
    ports:
      - "8080:8080"
 
  db:
    image: postgres:15
    environment:
      - POSTGRES_DB=myapp
    volumes:
      - pgdata:/var/lib/postgresql/data
 
volumes:
  pgdata:

Kubernetes (production-grade)

yaml
# deployment.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: qqq-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: qqq-app
  template:
    spec:
      containers:
      - name: qqq
        image: qrunio/qqq-runtime:latest
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
          limits:
            memory: "2Gi"
            cpu: "1000m"

Traditional VM (Java deployment)

bash
# Build your application
mvn clean package
 
# Copy to server
scp target/my-app.jar server:/opt/qqq/
 
# Run with Java
java -jar /opt/qqq/my-app.jar

What You Manage

  • Server provisioning and configuration
  • Database setup and backups
  • SSL certificate management
  • Load balancer configuration
  • Monitoring and alerting
  • Security patches and updates
  • Scaling decisions

Self-Hosting Costs

The costs depend on your infrastructure choices:

| Component | AWS | GCP | Azure | |-----------|-----|-----|-------| | Small app (2GB) | ~$50/mo | ~$45/mo | ~$55/mo | | Medium app (8GB) | ~$150/mo | ~$140/mo | ~$160/mo | | Database (RDS/Cloud SQL) | ~$50-200/mo | ~$50-180/mo | ~$60-210/mo |

Plus engineering time for operations, which varies by team.

Comparing the Options

| Aspect | qRun | Self-Hosted | |--------|------|-------------| | Time to deploy | Minutes | Hours to days | | Operational burden | None | Significant | | Scaling | Automatic | Manual or configured | | Cost predictability | Fixed tiers | Variable | | Data location | qRun regions | Your choice | | Customization | Limited | Unlimited | | Compliance | SOC 2 included | Your responsibility | | Support | Included | Community or paid |

Hybrid Approaches

You're not locked into one or the other. Common patterns:

Development on qRun, Production Self-Hosted

bash
# Dev/staging on qRun for convenience
qrun deploy --app my-app --env staging
 
# Production on your infrastructure
kubectl apply -f production/

Start qRun, Graduate to Self-Hosted Many teams start with qRun for speed, then migrate to self-hosting as they grow and want more control.

Self-Hosted Core, qRun for Auxiliary Run your main application self-hosted but use qRun for non-critical services or experiments.

Migration Between Options

Moving from qRun to self-hosting (or vice versa) is straightforward:

bash
# Export your application from qRun
qrun export --app my-app --output ./my-app-export
 
# This gives you:
# - Application JAR/container
# - Database dump
# - Environment configuration
# - File storage contents
 
# Deploy to your infrastructure
docker load < my-app-export/image.tar
psql mydb < my-app-export/database.sql

The reverse works too. No code changes required.

Decision Checklist

Go with qRun if:

  • [ ] You don't have dedicated DevOps resources
  • [ ] Time to market is critical
  • [ ] You want predictable costs
  • [ ] You're okay with qRun's regions (US, EU)
  • [ ] You prefer included support

Go with Self-Hosting if:

  • [ ] You have specific compliance requirements
  • [ ] You need data in specific regions
  • [ ] You have existing infrastructure/team
  • [ ] You want maximum customization
  • [ ] You're comfortable with operations

Our Recommendation

For most teams starting out, we recommend qRun. The managed platform lets you focus on building your application rather than operating infrastructure. You can always migrate to self-hosting later when you have specific requirements that demand it.

If you have existing DevOps expertise and infrastructure, or strict compliance requirements, self-hosting gives you complete control while still benefiting from qqq's productivity gains.

The beauty of qqq is that this isn't a one-way door. Start where it makes sense, and move when you need to.


Ready to deploy?

Read next

Ready to build faster?