Service Basics
Learn how to configure services in Blazing Core Compose
Services are the core building blocks of your application in Blazing Core Compose. Each service represents a containerized workload with its own configuration, resources, and scaling policies.
Service Definition
A service is defined under the services block:
Minimal Service
The smallest viable service configuration:
This creates a single replica with fixed resources.
Complete Service Anatomy
Here's a fully configured service with all available options:
Field Reference
Required Fields
| Field | Type | Description | Example |
|-------|------|-------------|---------|
| image | string | Container image (registry/name:tag) | nginx:latest |
| cpu | number | CPU cores (can be fractional) | 2 or 0.5 |
| memory | string | Memory allocation with unit | 4Gi or 512Mi |
Container Configuration
Image
Supported registries:
- Docker Hub:
nginx:latest - GitHub Container Registry:
ghcr.io/user/image:tag - Google Container Registry:
gcr.io/project/image:tag - Private registries:
registry.example.com/image:tag
Command and Args
Override container entrypoint and arguments:
Note: command replaces ENTRYPOINT, args replaces CMD.
Resource Allocation
CPU
Specify CPU cores (fractional or integer):
Cost Impact: Linear scaling (2 CPU = 2x cost of 1 CPU)
Memory
Specify memory with units:
Supported Units: Mi (mebibytes), Gi (gibibytes)
Cost Impact: Linear scaling (4Gi = 2x cost of 2Gi)
Environment Variables
Variables (Plain Text)
Note: All values are strings (quote numbers).
Secrets (Encrypted)
Secrets are:
- Encrypted at rest
- Injected as environment variables
- Never logged
- Rotatable via API
Create secrets via CLI:
Service Naming
Service names must:
- Be lowercase alphanumeric
- Start with a letter
- Use hyphens for word separation
- Be 1-63 characters long
Good Names:
Bad Names:
Multi-Service Applications
Define multiple services in one deployment:
Service Communication
Services within the same cluster can communicate via DNS:
DNS Format: {service-name}:{port}
Resource Sizing Guide
CPU Recommendations
| Workload Type | CPU | Example | |---------------|-----|---------| | Static site | 0.25-0.5 | Simple HTML/JS | | API server | 1-2 | REST/GraphQL API | | Web app | 2-4 | Next.js, React SSR | | Worker | 4-8 | Data processing | | Batch job | 8-16 | ML training, encoding |
Memory Recommendations
| Workload Type | Memory | Example | |---------------|--------|---------| | Static site | 512Mi-1Gi | nginx, S3 proxy | | API server | 2Gi-4Gi | Node.js, Go API | | Web app | 4Gi-8Gi | Rails, Django | | Worker | 8Gi-16Gi | Python workers | | Database | 16Gi-32Gi+ | PostgreSQL, MongoDB |
Right-Sizing Example
Start conservative, scale up based on metrics:
Phase 1: Initial deployment
Phase 2: After monitoring (CPU at 80%)
Phase 3: After growth (scaling frequently)
Health Checks
Liveness Probe
Check if container is alive:
Behavior: Restart container if checks fail.
Readiness Probe
Check if container is ready for traffic:
Behavior: Remove from load balancer if checks fail.