Containers, CI/CD and serverless delivery

Generated by Claude through GigAI 0.1.11.10 on 2026-10-11.

Concept: DevOps · also covers Serverless, Customer and production deployment · Step 27 of 34 in AI forward deployed engineer · version 1

Practice this

On this page

Containers, pipelines and serverless functions are the packaging and delivery mechanics behind every customer deployment. The forward deployed twist is that the registry, the cluster and the pipeline often belong to someone else, so artifacts must be portable, configurable from outside, and promotable through a process you do not control. This lesson focuses on those constraints rather than on the basics of each tool.

Read more

How it is done in practice

A team keeps a single release pipeline that produces signed images and a versioned chart, plus a small set of per-customer values files that contain no secrets. Each customer environment pulls a pinned release, either through the customer's own pipeline or through a GitOps controller in the cluster, and secrets come from the customer's secret store. Short event-driven pieces run as functions; the agent runtime and anything streaming or long-lived runs as containers. Release notes list configuration changes explicitly, because the person applying the upgrade is often a customer platform engineer.

Technologies

DockerKubernetesHelmGitHub ActionsArgo CDFluxAWS LambdaGoogle Cloud RunAzure FunctionsAWS Secrets ManagerHashiCorp VaultSigstore Cosign

Diagram

flowchart LR
  SRC[Source repo] --> CI[Vendor CI: build, test, scan, sign]
  CI --> REL[Versioned release: images by digest and chart]
  REL --> MIR[Customer registry mirror and scan]
  MIR --> GIT[Customer config repo with values]
  GIT --> CD[GitOps controller in cluster]
  CD --> NS[Application namespace]
  SEC[Customer secret manager] --> NS
flowchart LR
  SRC[Source repo] --> CI[Vendor CI: build, test, scan, sign]
  CI --> REL[Versioned release: images by digest and chart]
  REL --> MIR[Customer registry mirror and scan]
  MIR --> GIT[Customer config repo with values]
  GIT --> CD[GitOps controller in cluster]
  CD --> NS[Application namespace]
  SEC[Customer secret manager] --> NS

Code

yaml
name: release
on:
  push:
    tags: ['v*']
permissions:
  id-token: write   # short-lived cloud credentials via OIDC
  contents: read
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: arn:aws:iam::ACCOUNT_ID:role/ci-release
          aws-region: us-east-1
      - run: docker build -t REGISTRY_HOST/app:${GITHUB_REF_NAME} .
      - run: docker push REGISTRY_HOST/app:${GITHUB_REF_NAME}

Subtopics

Images as the unit of delivery

What changes when the registry is not yours

A customer will usually mirror your images into their own registry and scan them before anything runs. That makes image hygiene a delivery concern: small base images, no secrets in layers, a non-root user, a published software bill of materials, and signatures the customer can verify. Reference images by digest in manifests so the mirrored copy is provably the one you tested. Build for the CPU architecture they run, and keep the registry host a configurable value everywhere.

Packaging for a customer Kubernetes cluster

A chart that survives someone else's cluster

Kubernetes gives you declarative deployment, service discovery, rollouts and self-healing, but a customer cluster arrives with its own admission policies, ingress controller, storage classes and quotas. Ship a chart whose values expose those choices: ingress class, storage class, resource requests, node selectors, image registry, and existing secret names. Request namespace-scoped permissions where possible, since cluster-wide roles and custom resource definitions trigger extra review. Test the chart on a locked-down cluster before the customer does.

CI/CD across the vendor and customer boundary

Build once, promote through their gates

Split the pipeline at the artifact. Your side builds, tests, scans and signs a versioned release; the customer side pulls that release and promotes it through their environments under their change process. Authenticate pipelines to clouds with short-lived federated tokens rather than stored keys; GitHub Actions supports this through OpenID Connect. Where the customer forbids outside pipelines from touching their cluster, use a pull model: a GitOps controller inside the cluster watches a repository and applies changes, so nothing reaches in from outside.

Serverless delivery and where it fits LLM systems

Strengths and limits

AWS Lambda runs code without provisioning servers, scales with request volume and bills for compute time used, which suits webhook handlers, document-triggered ingestion steps and glue between customer systems. LLM workloads strain the model in specific ways: a function has a maximum execution time, so a long agent loop or a slow model call can be cut off; time spent waiting on a model response is billed; cold starts add latency to interactive paths; and streaming responses need a supported invocation mode. A common split is functions for event-driven edges and short tool calls, and containers or a durable workflow engine for long-running agent runs. Check the customer's concurrency quotas and whether functions must attach to a private network, since both change behavior.

Configuration and secrets per customer environment

One artifact, many environments

The twelve-factor rule is that configuration, meaning everything likely to vary between deploys, lives in the environment and not in the code. The test is whether the codebase could be made public without leaking a credential. For multi-customer delivery this is the mechanism that lets one image serve every customer: model endpoint, model name, database address, feature flags and tenant identifiers are all injected at deploy time. Avoid named environment groups baked into code such as a per-customer settings file; they multiply with every deployment. Secrets come from the customer's secret manager through workload identity, mounted or fetched at start. Validate configuration at startup and fail fast with a clear message, because a person on the customer's team, not you, may be reading the log.

Sources

Related lessons

Practice this
Deploying into customer clouds: AWS, Google Cloud and AzureNetworking for private, air-gapped and classified customer environments