Instance Types Reference¶

Complete specification of available compute instance types

This document provides detailed information about instance types in Airbase, including resource allocations, use cases, and selection guidance.

Overview¶

Instance types define the compute resources (CPU and memory) allocated to your application containers. Choosing the right instance type ensures optimal performance while managing costs.

Key concepts: - Instance type: Combination of CPU and memory resources - Vertical scaling: Change instance type to get more/less resources - Resource limits: Hard limits enforced by platform - Cost optimization: Right-sizing for your workload

Available Instance Types¶

Summary Table¶

Detailed Specifications¶

nano¶

Resources: - vCPU: 0.25 (250 millicores) - Memory: 500MB - Ephemeral Storage: 500MB - Disk I/O: Standard - Network: Standard

Use cases: - Simple REST APIs - Microservices - Health check endpoints - Static file servers - Lightweight proxy services

Limitations: - Not suitable for memory-intensive operations - Limited concurrent request handling - Cannot run heavy data processing

Example applications:

{
  "instanceType": "nano"
}

Performance characteristics: - Requests/second: ~100-500 (simple endpoints) - Startup time: 5-10 seconds - Cold start: Fast

b.small¶

Resources: - vCPU: 0.5 (500 millicores) - Memory: 1GB - Ephemeral Storage: 500MB - Disk I/O: Standard - Network: Standard

Use cases: - Standard web applications - Data visualization dashboards (Streamlit) - APIs with moderate traffic - Background workers - Frontend single-page applications

Limitations: - May struggle with large datasets (>100MB in memory) - Limited for heavy computational tasks - Moderate concurrent connections

Example applications:

{
  "instanceType": "b.small"
}

Performance characteristics: - Requests/second: ~500-2000 (typical endpoints) - Startup time: 10-20 seconds - Memory pressure: Starts at ~60% usage

Recommended for: - Default choice for most applications - Good balance of cost and performance - Streamlit applications (minimum recommended)

Resource Limits¶

CPU Limits¶

CPU allocation: - Expressed in millicores (1000 millicores = 1 vCPU) - Guaranteed minimum allocation - Can burst above limit if cluster has capacity - Throttled if exceeding sustained usage

Example: - nano (250m): Can use up to 25% of 1 CPU core - b.small (500m): Can use up to 50% of 1 CPU core

CPU throttling:

If your app consistently uses more CPU than allocated:
- App will be throttled (slowed down)
- Response times increase
- Consider upgrading instance type

Memory Limits¶

Memory allocation: - Hard limit (cannot exceed) - Out-of-Memory (OOM) kills if exceeded - Includes all process memory

OOM behavior:

If app exceeds memory limit:
1. Container is killed (OOM Kill)
2. Kubernetes restarts container
3. Application restarts from scratch

Memory includes: - Application heap - Application stack - Loaded libraries - File buffers - Cache

Monitoring memory: - Check application logs in Airbase Console - Search for: oom, OOM, memory, killed

Signs you need more memory: - Frequent container restarts - OOM kill messages in logs - Application crashes under load - Degraded performance over time

Choosing the Right Instance Type¶

Decision Matrix¶

Start with nano if:¶

• ✅ Simple REST API endpoints
• ✅ Minimal data processing
• ✅ Low traffic (<100 requests/minute)
• ✅ No in-memory data storage
• ✅ Quick response times (<100ms processing)
• ✅ Static sites

Upgrade to b.small if:¶

• ✅ Standard web application
• ✅ Data visualization (Streamlit)
• ✅ Moderate traffic (100-1000 requests/minute)
• ✅ Small to medium datasets (<100MB)
• ✅ Database connections with pooling
• ✅ Complex business logic

Configuration¶

Setting Instance Type¶

In airbase.json:

{
  "framework": "container",
  "handle": "myteam/myapp",
  "port": 3000,
  "instanceType": "b.small"
}

Supported values: - nano (default if not specified) - b.small

Changing Instance Type¶

Update airbase.json:

{
  "instanceType": "b.small"
}

Rebuild and redeploy:

# Rebuild container (no rebuild needed, just config change)
airbase container deploy --yes staging

Changes take effect: - Immediately on next deployment - Kubernetes replaces existing pods - Brief downtime during pod replacement (~10-30 seconds)

Performance Optimization¶

Right-Sizing Strategy¶

1. Start small:

{
  "instanceType": "nano"
}

2. Monitor performance: - Check logs in Airbase Console for performance issues - Monitor for OOM kills, slow responses, errors

3. Upgrade if needed:

{
  "instanceType": "b.small"
}

4. Repeat until optimal: - Monitor CPU and memory usage - Check response times - Observe error rates

Vertical vs Horizontal Scaling¶

Vertical Scaling (Increase Instance Type)¶

Pros: - Simple configuration change - No code changes needed - Single instance to manage

Cons: - Limited by maximum instance size - Single point of failure - May be cost-inefficient at scale

Use vertical scaling for: - Memory-bound applications - Single-threaded applications - Initial scaling needs

Example:

// Before
{"instanceType": "nano"}

// After
{"instanceType": "b.small"}

Horizontal Scaling (Multiple Instances)¶

Note: Horizontal scaling (multiple replicas) is not yet available in Airbase. Contact platform team for roadmap.

Future capability:

{
  "instanceType": "b.small",
  "replicas": 3
}

When to consider (future): - High availability requirements - Traffic exceeds single instance capacity - Better cost optimization

Framework-Specific Recommendations¶

Node.js Applications¶

Minimum recommended:

{
  "instanceType": "nano"
}

Upgrade to b.small if: - Using in-memory session storage - Processing file uploads - Complex business logic - WebSocket connections - High concurrent connections - Large JSON payloads

Memory management:

// Set Node.js memory limit
// In Dockerfile
ENV NODE_OPTIONS="--max-old-space-size=400"

// For nano (500MB total, ~400MB safe for Node.js)
// For b.small (1GB total, ~800MB safe)

Python Applications¶

Minimum recommended:

{
  "instanceType": "b.small"
}

Python is memory-intensive: - Flask/FastAPI: b.small minimum - Streamlit: b.small minimum - Data processing: b.small (optimize for memory efficiency)

Considerations for nano: - Not recommended for most Python applications due to memory constraints - May work for very simple Flask/FastAPI APIs with no data processing

Worker configuration:

# Gunicorn workers based on instance type

# nano: Not recommended for Gunicorn
# b.small: 1-2 workers
gunicorn --workers 1 app:app  # Start with 1, monitor memory usage

Memory optimization tips: - Keep datasets small (<100MB) - Use generators for large data processing - Avoid loading entire datasets into memory - Consider streaming responses for large payloads

Static Sites (Nginx)¶

Recommended:

{
  "instanceType": "nano"
}

Nginx is lightweight: - nano handles most static sites - b.small for high-traffic sites - Consider CDN for very high traffic

Upgrade to b.small if: - Very high traffic (>1000 requests/minute) - Large static assets - Complex Nginx configurations

Monitoring and Troubleshooting¶

Signs of Insufficient Resources¶

CPU Bottleneck Symptoms:¶

• Slow response times under load
• Increasing latency over time
• High CPU usage in logs

Solution: Upgrade instance type

Memory Bottleneck Symptoms:¶

• Container restarts
• OOM kill messages in logs
• Application crashes
• Memory errors

Solution: Upgrade instance type or optimize memory usage

Checking Resource Usage¶

View logs for resource issues: - Open logs in Airbase Console - Search for OOM kills: oom, memory, killed - Search for errors: error, Error, ERROR

Monitor application behavior: - Response times increase under load → Need more CPU - Crashes with large requests → Need more memory - Slow data processing → Need more CPU/memory

Cost Considerations¶

Instance Type Costs¶

Relative costs (exact pricing contact platform team): - nano: 1x (baseline) - b.small: ~2x

Cost Optimization Tips¶

1. Start small and scale up:

// Start
{"instanceType": "nano"}

// Only upgrade if needed
{"instanceType": "b.small"}

2. Right-size for actual usage: - Don't over-provision "just in case" - Monitor actual resource usage - Adjust based on metrics

3. Consider application optimization: - Optimize code before scaling up - Add caching layers - Use efficient algorithms - Minimize memory allocations

4. Use staging for testing:

# Test with smaller instance in staging
airbase container deploy --yes staging

# Only upgrade production if needed

Best Practices¶

✅ Do's¶

• Start with recommended minimum for your framework
• Monitor resource usage regularly
• Upgrade based on data not assumptions
• Test in staging before changing production
• Document your choice in project README
• Review periodically as traffic patterns change

❌ Don'ts¶

• Don't over-provision - start small and scale up
• Don't ignore OOM kills - upgrade memory if frequent
• Don't stay on nano if you see performance issues
• Don't upgrade without understanding the bottleneck
• Don't forget to update airbase.json after testing

Examples¶

Example: Simple REST API¶

Application: - Express.js REST API - 10 endpoints - PostgreSQL connection - Low traffic (<100 requests/minute)

Recommended:

{
  "instanceType": "nano"
}

Example: Streamlit Dashboard¶

Application: - Streamlit data dashboard - Pandas/Plotly visualizations - Loading 50MB CSV files - 20-50 concurrent users

Recommended:

{
  "instanceType": "b.small"
}

Memory optimization: - Keep datasets under 100MB - Use data sampling for large datasets - Implement caching for expensive computations

Example: Moderate-Traffic API¶

Application: - Flask REST API - Moderate traffic (500-1000 requests/minute) - Database connection pooling - 1-2 Gunicorn workers

Recommended:

{
  "instanceType": "b.small"
}

Optimization tips: - Implement caching for frequently-accessed data - Use connection pooling for database - Keep response payloads small - Monitor memory usage to avoid OOM kills

See Also¶

• Reference: airbase.json Configuration - Project configuration
• How-To: Build and Deploy - Deployment workflow
• Explanation: Architecture - Platform architecture