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.

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:
# 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
# - BackupsWhat'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)
# 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)
# 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)
# 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.jarWhat 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
# 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:
# 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.sqlThe 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?