WorkingDirectory icon
Clone icon
Build icon
Switch icon
Run icon
Commands icon
Docker icon
GCloudCLI icon
AzCLI icon

Multi-cloud deployment pipeline with Docker, ngrok, GCP Cloud Run, and Azure Container Apps

Build a Docker image from any GitHub repo and deploy it to local, GCP Cloud Run, or Azure with a single Kestra flow driven by one cloud_name input.

Categories
CloudInfrastructure

Ship the same container to multiple clouds without maintaining a separate pipeline for each target. This Kestra flow clones a public GitHub repository, builds and pushes a Docker image to Docker Hub, then deploys that image to local Docker, GCP Cloud Run, or Azure Container Instances based on a single cloud_name input. It solves the common problem of fragmented, copy-pasted CI scripts where build logic and per-cloud deployment logic drift apart and become impossible to audit.

How it works

  1. A io.kestra.plugin.core.flow.WorkingDirectory task wraps the build stage so all steps share one workspace.
  2. io.kestra.plugin.git.Clone checks out the repo from github_repo at github_repo_branch.
  3. io.kestra.plugin.docker.Build builds the image from the repo Dockerfile, tags it user/app:tag, and pushes it to Docker Hub with push: true.
  4. io.kestra.plugin.core.flow.Switch reads cloud_name and routes to one of three cases:
    • local: io.kestra.plugin.docker.Run runs the container with a host port binding, then io.kestra.plugin.scripts.shell.Commands exposes it publicly through an ngrok static domain.
    • gcp: io.kestra.plugin.gcp.cli.GCloudCLI runs gcloud run deploy to push the image to Cloud Run.
    • azure: io.kestra.plugin.azure.cli.AzCLI runs az container create to launch an Azure Container Instance.

What you get

  • One pipeline that builds once and deploys anywhere across three environments.
  • Public Docker Hub image you can reuse across targets.
  • Instant public URL for local testing via ngrok.
  • Parameterized inputs for repo, branch, image tag, ports, and application name.

Who it's for

  • Platform and DevOps engineers standardizing multi-cloud deployments.
  • Backend teams that want repeatable build-and-deploy without per-cloud CI YAML.
  • Developers demoing an app on local, GCP, or Azure on demand.

Why orchestrate this with Kestra

Docker, gcloud, and az each have their own CLI but no shared scheduler, retry policy, or lineage across clouds. Kestra unifies them in one declarative YAML flow: a single Switch chooses the target, every task run is logged and observable, retries and error handling are built in, and the build artifact is traced through to each deployment. You get event triggers and scheduling that a standalone container CLI simply cannot provide.

Prerequisites

  • A public GitHub repository containing a Dockerfile.
  • A Docker Hub account with push access.
  • GCP and/or Azure accounts if deploying to those clouds.
  • An ngrok account with a static domain for local public exposure.

Secrets

  • DOCKER_HUB_USERNAME, DOCKER_HUB_PAT
  • NGROK_AUTH_TOKEN, NGROK_STATIC_DOMAIN
  • GCP_PROJECT_ID, GCP_SERVICE_ACCOUNT, GCP_REGION
  • AZURE_APP_ID, AZURE_SERVICE_PRINCIPAL_PASSWORD, AZURE_TENANT_ID, AZURE_RESOURCE_GROUP, AZURE_LOCATION

Quick start

  1. Add the secrets above for the target you intend to use.
  2. Set cloud_name to local, gcp, or azure.
  3. Point github_repo and github_repo_branch at your app.
  4. Set docker_user_account_name, application_name, and docker_image_tag.
  5. Execute the flow and watch the build then the matching deployment case run.

How to extend

  • Add a new Switch case for AWS ECS or Kubernetes.
  • Swap WorkingDirectory to build from a private repo with Git credentials.
  • Add a Schedule or webhook trigger to redeploy on every push.
  • Add post-deploy health checks or Slack notifications on completion.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.