Self-Hosted
Deploy and operate ByteChef on your own infrastructure.
Run ByteChef on your own infrastructure — Docker, Kubernetes, AWS, Azure, Google Cloud, or DigitalOcean — with full control over data, networking, and customization.
Installation
Pick a deployment target and get an instance running.
Configuration
Configuration, environment variables.
Management
Upgrades, and backups.
Architecture
Understand the layered architecture you're deploying.
Deployment models
The same artifact runs in two shapes. Pick by workload, not by company size.
The server
One process carrying the workflow engine, every domain service, and the HTTP API. PostgreSQL is the only hard dependency; Redis is optional. This is the fastest path to a working environment and what almost every deployment should run. Start at Local Docker.
To handle more load, run several instances against the same database. A handful of settings have to be aligned first — a shared encryption key, a shared message broker and cache, a fixed remember-me key, and migrations owned by one instance — see Running multiple instances.
Single-shot
The runtime job runner boots, executes exactly one
workflow, and exits with the workflow's status. No database, no broker, no triggers — for batch runs
whose schedule already lives in Airflow, a CI pipeline, or a Kubernetes CronJob. Enterprise Edition.
Supported substrates
| Substrate | Recommended for | Notes |
|---|---|---|
| Docker / Docker Compose | Dev, demo, and small production | A reference docker-compose.yml is shipped with the platform, pulling docker.bytechef.io/bytechef/bytechef. |
| Kubernetes | Production deployments of any size | A Helm chart for the monolith lives at kubernetes/helm/bytechef. |
| AWS | Cloud-native deployments on AWS | EC2 or ECS; SQS as the message broker, S3 for file storage, and EventBridge Scheduler as the scheduler backend are all supported. |
| Google Cloud | Cloud-native deployments on GCP | Postgres on Cloud SQL. |
| Azure | Cloud-native deployments on Azure | Postgres on Azure Database for PostgreSQL. |
| DigitalOcean | Small to mid-size deployments | Reference deployment available. |
The Helm chart templates the deployment, service, ingress, ConfigMap, Secret, service account, and an
HPA. Note that it ships replicaCount: 1 and sets no broker or cache variables, so the default values
run the in-memory broker. Raising replicaCount (or enabling the HPA) on its own gives you replicas
that cannot hand each other work — add the shared-instance settings under env.normal first, per
Running multiple instances.
Your perimeter, your secrets
- Credentials never leave your network. Connection credentials are encrypted at rest in your own database with a key you supply — see Encryption of stored credentials.
- Telemetry is opt-in and points at your stack. OpenTelemetry export ships disabled; every
signal stays off until you set an endpoint and flip the flag
(Observability). Product
analytics are the exception:
bytechef.analytics.enabledisfalsein the base configuration, but theprodprofile the published container image runs sets it totrue, so setBYTECHEF_ANALYTICS_ENABLED=falseexplicitly if you do not want it. - AI traffic is routable. You choose which providers receive prompts and where their keys live.
- Nothing is settings-screen-only. Every instance-wide option is externalized configuration, so the same image behaves differently per environment based on what you pass in (Configuration).
How is this guide?
Last updated on