Serverless and containers solve different problems. Choosing the wrong one leads to either unnecessary costs or unnecessary complexity. This guide provides a decision framework based on workload characteristics, compares costs at different traffic levels, quantifies cold start impact, and identifies workloads that should never be serverless. The answer is rarely "always one or the other" but rather "the right tool for each workload."
Datadog's 2026 Container and Serverless report found that 58% of organizations use both containers and serverless in production. Organizations that match workload type to execution model spend 35% less on compute compared to those using a single model for everything.
---
The Decision Framework
Answer these five questions about your workload. The answers determine whether serverless or containers are the better fit.
| Question | Serverless | Containers |
| Traffic pattern? | Spiky, unpredictable | Steady, predictable |
| Execution duration? | < 15 seconds | > 15 seconds or long-running |
| State requirements? | Stateless | Stateful or in-memory state |
| Cold start tolerance? | Acceptable (100-500ms) | Not acceptable (< 10ms) |
| Concurrency model? | Independent requests | Shared resources/connections |
| Team expertise? | Limited ops capacity | DevOps/platform experience |
| Vendor lock-in tolerance? | Acceptable | Minimal lock-in preferred |
Ideal Serverless Workloads
- Webhook handlers (Stripe, GitHub, etc.)
- Image/video processing triggers
- Scheduled tasks (cron-like)
- Low-traffic API endpoints (< 100 requests/minute)
- Event-driven data processing
- Prototype/MVP APIs
Ideal Container Workloads
- Web applications with persistent connections
- APIs with > 100 requests/minute sustained
- WebSocket servers
- Background workers with queue processing
- Applications requiring local file system access
- ML model serving (cold starts are unacceptable)
- Databases and stateful services
---
Cost Comparison at Different Scales
The cost crossover point depends on traffic volume. Serverless is cheaper at low traffic; containers win at sustained high traffic.
| Monthly Requests | Serverless (Lambda) | Container (Arxentra VPS) | Winner |
| 100,000 | $0.44 | $18.76/mo (1 vCPU, 1 GB) | Serverless |
| 500,000 | $2.22 | $18.76/mo (1 vCPU, 1 GB) | Serverless |
| 1,000,000 | $4.45 | $18.76/mo (1 vCPU, 1 GB) | Serverless |
| 5,000,000 | $22.25 | $21.68/mo (1 vCPU, 2 GB) | Container (barely) |
| 10,000,000 | $44.50 | $21.68/mo (1 vCPU, 2 GB) | Container |
| 50,000,000 | $222.48 | $33.36/mo (2 vCPU, 4 GB) | Container |
| 100,000,000 | $444.96 | $56.72/mo (4 vCPU, 8 GB) | Container |
*Serverless costs assume 128MB memory, 2-second average duration: $0.20 per 1M requests plus 0.256 GB-seconds x $0.0000166 per request, about $4.45 per million, before the Lambda free tier. Container costs assume a single Arxentra container running nginx + application server 24/7 at the size shown in each row, billed at list usage rates on the Pricing page ($0.008/vCPU-hr, $0.004/GB-hr of RAM), before any included plan hours or bundle discounts, plus the $10/month Developer plan fee.*
The crossover typically occurs around 4-5 million requests per month ($18.76 / $4.45 per million = 4.2M on a 1 GB container; $21.68 / $4.45 = 4.9M on a 2 GB one). Below this, serverless is cheaper. Above this, containers are cheaper - by roughly 6.7x at 50 million requests and 7.8x at 100 million.
<h1>Cost model calculation</h1>
serverless_cost:
per_request: 0.0000002 # $0.20 per 1M requests
per_gb_second: 0.0000166 # $0.0000166 per GB-second
memory_gb: 0.128
avg_duration_seconds: 2
monthly_requests: 5000000
compute_cost: 21.25 # 5M x 0.128 x 2 x 0.0000166
request_cost: 1.00 # 5M x 0.0000002
total: 22.25
container_cost:
arxentra_compute: 11.68 # 1 vCPU + 2 GB RAM, 24/7 usage-based
platform_plan: 10.00 # Developer plan fee
total: 21.68
savings: 3 # percent: (22.25 - 21.68) / 22.25 - roughly break-even at 5M
Check Pricing for current Arxentra usage rates.
---
Cold Start Impact
Cold starts occur when a serverless function has not been invoked recently and needs to initialize. This adds 100ms-5000ms to the first request.
| Runtime | Cold Start (p50) | Cold Start (p99) | Warm Response |
| Node.js | 150ms | 450ms | 5-15ms |
| Python | 200ms | 600ms | 8-20ms |
| Go | 80ms | 200ms | 2-8ms |
| Java | 800ms | 3000ms | 5-15ms |
| .NET | 400ms | 1200ms | 5-15ms |
When Cold Starts Matter
- User-facing APIs: A 500ms cold start on a login endpoint is noticeable
- Payment processing: Webhook receivers with cold starts may timeout
- Real-time features: Chat, notifications, or live updates cannot tolerate cold starts
- Health checks: Load balancers may mark cold-starting functions as unhealthy
When Cold Starts Do Not Matter
- Background processing (email sending, report generation)
- Scheduled tasks (running every hour)
- Asynchronous event handlers (file uploads, log processing)
- Internal tools with patient users
---
Hybrid Architecture: Best of Both
Most production systems benefit from using both. The pattern is: containers for the core application, serverless for peripheral workloads.
<h1>Hybrid architecture example</h1>
core_application:
deployment: container # Arxentra VPS
components:
- web_server: nginx + React SPA
- api_server: FastAPI (3 workers)
- database: Managed PostgreSQL
- cache: Redis
serverless_workloads:
- image_resizer:
trigger: object_storage_upload
runtime: python3.12
memory: 512MB
timeout: 30s
- email_sender:
trigger: event_queue
runtime: nodejs20
memory: 128MB
timeout: 10s
- daily_report:
trigger: cron(0 6 * * *)
runtime: python3.12
memory: 256MB
timeout: 300s
This architecture keeps the predictable, high-traffic workload on cost-effective containers while using serverless for bursty, event-driven tasks. See Services Overview for Arxentra container and event processing options.
---
Stateful Workloads: Containers Only
These workloads should never be serverless:
---
Migration Path: Serverless to Containers
When your serverless costs exceed container costs, migrate using this checklist.
- [ ] Identify all serverless functions by category (API, events, scheduled)
- [ ] Group related functions into services (1 container per service)
- [ ] Containerize with Docker and test locally
- [ ] Deploy to Arxentra VPS with health checks
- [ ] Route traffic gradually (10% > 50% > 100%)
- [ ] Monitor for 1 week before decommissioning serverless
- [ ] Update CI/CD pipelines
---
Frequently Asked Questions
At what scale should I switch from serverless to containers?
When your monthly serverless bill exceeds the cost of a container that could handle the same traffic. This typically happens at around 4-5 million requests per month for API workloads. For compute-heavy workloads (image processing, data transformation), the crossover is lower.
Can I use containers without Kubernetes?
Yes. Docker containers on a single VPS with Docker Compose are simpler and sufficient for most applications handling under 10,000 requests per minute. Kubernetes adds value when you need auto-scaling across multiple nodes, zero-downtime deployments, and self-healing. Start simple and adopt Kubernetes when the operational benefits outweigh the complexity. See Documentation for Docker deployment guides.
Is serverless truly "no ops"?
No. You still manage deployments, monitoring, logging, IAM permissions, API gateways, environment variables, and debugging. The operational model is different (no OS patching, no capacity planning) but not absent. Teams typically spend 40-60% less time on ops with serverless compared to containers.
How do I handle database connections in serverless?
This is the most common serverless pain point. Each function invocation creates a new database connection. With 100 concurrent invocations, you have 100 connections. Solutions: use a connection proxy (RDS Proxy, PgBouncer), use HTTP-based database APIs, or use DynamoDB/Firestore which handle connections internally.
What about serverless containers (Fargate, Cloud Run)?
Serverless containers combine container portability with serverless scaling. They cost 2-3x more than dedicated containers but less than maintaining Kubernetes. They are a good middle ground when you want containers without managing servers but have outgrown Lambda/Functions. Arxentra VPS with auto-scaling provides similar benefits at lower cost. Contact us for architecture recommendations.