IBM Code Engine: Serverless Containers

IBM Code Engine Overview

IBM Cloud Code Engine is a fully managed serverless platform that runs containerized workloads without requiring you to manage servers, clusters, or infrastructure. Code Engine supports three workload types: applications (long-running HTTP services that scale to zero), batch jobs (run-to-completion tasks), and function deployments (single event handlers). Unlike platforms limited to specific runtimes, Code Engine runs any container image, giving you complete flexibility in your technology stack.

Code Engine is built on top of open-source Knative and Kubernetes, but you never interact with Kubernetes directly. The platform handles autoscaling (including scale-to-zero), traffic management, TLS termination, and integration with IBM Cloud services. You pay only for the vCPU and memory consumed while your workloads are actively processing requests or running jobs — there is no charge when your application is scaled to zero.

This guide covers Code Engine projects, applications, jobs, functions, build strategies, event subscriptions, secrets and configmaps, custom domains, and production best practices.

Projects

A Code Engine project is the top-level grouping construct, similar to a Kubernetes namespace. All applications, jobs, and functions within a project share the same networking configuration, secrets, and configmaps. Create separate projects for different environments (dev, staging, production) or different applications.

# Create a project
ibmcloud ce project create --name prod-microservices

# Select the project for subsequent commands
ibmcloud ce project select --name prod-microservices

# List all projects
ibmcloud ce project list

Applications

Applications are long-running HTTP services that automatically scale based on incoming traffic. When no traffic arrives, applications can scale to zero instances, eliminating all compute costs. When traffic resumes, Code Engine automatically provisions instances to handle the load.

# Deploy an application from a container image
ibmcloud ce app create --name api-gateway \
  --image us.icr.io/prod-ns/api-gateway:v2.1 \
  --cpu 1 --memory 4G \
  --min-scale 2 --max-scale 20 \
  --concurrency 100 \
  --port 8080 \
  --env NODE_ENV=production \
  --registry-secret icr-secret

# Update an application (triggers a new revision)
ibmcloud ce app update --name api-gateway \
  --image us.icr.io/prod-ns/api-gateway:v2.2

# Get application details and URL
ibmcloud ce app get --name api-gateway

# View application logs
ibmcloud ce app logs --name api-gateway --follow

Concurrency and Scaling

Code Engine autoscaling is driven by concurrency — the number of simultaneous requests each instance handles. Configure --concurrency based on your application's characteristics:

• High concurrency (100-500): I/O-bound services (API proxies, database queries, external API calls). Each instance handles many concurrent requests efficiently.
• Medium concurrency (10-50): Web applications with server-side rendering, moderate compute per request.
• Low concurrency (1-5): CPU-bound services (image processing, ML inference, video encoding). Each request consumes significant CPU.

Jobs

Jobs are run-to-completion workloads that process a task and exit. Jobs are ideal for batch processing, data pipelines, ETL operations, report generation, and any workload that does not serve HTTP traffic. Jobs support array parallelism, where multiple instances of the same job run in parallel with different array indices.

# Create a job definition
ibmcloud ce job create --name data-processor \
  --image us.icr.io/prod-ns/data-processor:v1.5 \
  --cpu 2 --memory 8G \
  --maxexecutiontime 3600 \
  --retrylimit 3 \
  --array-size 10

# Submit a job run
ibmcloud ce jobrun submit --job data-processor

# Submit a job run with custom environment variables
ibmcloud ce jobrun submit --job data-processor \
  --env BATCH_DATE=2024-06-01 \
  --env INPUT_BUCKET=raw-data

# Check job run status
ibmcloud ce jobrun list

# View job logs
ibmcloud ce jobrun logs --jobrun data-processor-run-1

Array Jobs

Array jobs run multiple instances of the same container in parallel. Each instance receives a unique index through the JOB_INDEX environment variable, which you use to partition your workload. For example, if processing 10,000 files, set--array-size 100 and have each instance process filesJOB_INDEX * 100 through (JOB_INDEX + 1) * 100 - 1.

Functions

Code Engine Functions are the simplest deployment model, similar to AWS Lambda or IBM Cloud Functions. You provide a single function handler that processes an event and returns a response. Functions support Node.js and Python runtimes with automatic dependency management.

# Create a function from inline code
ibmcloud ce fn create --name hello-world \
  --runtime nodejs-20 \
  --inline-code "function main(args) { return { body: 'Hello, World!' }; }" \
  --cpu 0.25 --memory 0.5G

Build Strategies

Code Engine can build container images directly from source code, eliminating the need for a separate CI/CD pipeline. Three build strategies are supported:

• Dockerfile: Standard Docker build using a Dockerfile in your repository.
• Cloud Native Buildpacks: Automatic detection and building of applications without a Dockerfile. Supports Node.js, Python, Java, Go, .NET, and Ruby.
• Source-to-Image: Red Hat S2I builder images for consistent, secure builds.

# Create a build from a Git repository
ibmcloud ce build create --name my-app-build \
  --source https://github.com/example/my-app \
  --strategy dockerfile \
  --size medium \
  --image us.icr.io/prod-ns/my-app \
  --registry-secret icr-secret

# Run the build
ibmcloud ce buildrun submit --build my-app-build

# Deploy directly from source (build + deploy in one step)
ibmcloud ce app create --name my-app \
  --build-source https://github.com/example/my-app \
  --strategy buildpacks

Event Subscriptions

Code Engine supports event-driven architectures through event subscriptions that trigger applications or jobs when events occur in other IBM Cloud services:

• Cloud Object Storage: Trigger when objects are created, updated, or deleted in a COS bucket.
• Cron: Trigger on a recurring schedule using cron expressions.
• IBM Cloud Event Notifications: Trigger from Event Notifications for multi-channel event routing.

# Create a COS event subscription
ibmcloud ce sub cos create --name cos-processor \
  --destination api-gateway \
  --bucket incoming-data \
  --event-type write \
  --prefix uploads/

# Create a cron subscription
ibmcloud ce sub cron create --name hourly-cleanup \
  --destination data-processor \
  --destination-type job \
  --schedule "0 * * * *" \
  --data '{"action": "cleanup"}'

Secrets and ConfigMaps

Code Engine supports Kubernetes-style secrets and configmaps for externalizing configuration from your container images. Secrets are encrypted at rest and can store credentials, API keys, and TLS certificates. ConfigMaps store non-sensitive configuration like feature flags and application settings.

# Create a secret
ibmcloud ce secret create --name db-credentials \
  --from-literal DB_HOST=db.example.com \
  --from-literal DB_PASSWORD=secure-password

# Create a configmap
ibmcloud ce configmap create --name app-config \
  --from-literal FEATURE_FLAG=true \
  --from-literal LOG_LEVEL=info

# Reference secrets in an application
ibmcloud ce app update --name api-gateway \
  --env-from-secret db-credentials \
  --env-from-configmap app-config

Custom Domains and TLS

By default, Code Engine provides a system-generated URL for each application. For production use, configure custom domains with your own TLS certificates:

# Create a TLS secret with your certificate
ibmcloud ce secret create --name my-tls-cert \
  --format tls \
  --cert-chain-file cert.pem \
  --private-key-file key.pem

# Map a custom domain
ibmcloud ce domainmapping create --name api.example.com \
  --target api-gateway \
  --tls-secret my-tls-cert

Production Best Practices

• Set --min-scale to at least 2 for production applications to provide high availability and eliminate cold starts.
• Use --max-scale to prevent unexpected cost spikes from traffic surges.
• Store images in IBM Container Registry with vulnerability scanning enabled.
• Use secrets for all sensitive configuration; never embed credentials in container images.
• Configure health checks (--probe-ready) to ensure traffic is only routed to healthy instances.
• Set appropriate resource limits (--cpu, --memory) to prevent resource starvation.
• Use service bindings to connect to IBM Cloud services with auto-injected credentials.
• Monitor with IBM Cloud Monitoring and forward logs to IBM Cloud Log Analysis.
• Implement graceful shutdown handling for the SIGTERM signal.
• Tag container images with specific versions rather than using :latest.