Automating Multi-Cloud VPS Deployment: Bulk Provisioning Hetzner and DigitalOcean with OpenTofu and GitHub Actions

Introduction: The Multi-Cloud Imperative in Modern Infrastructure

In contemporary cloud engineering, relying on a single Infrastructure-as-a-Service (IaaS) provider poses structural risks, including regional outages, vendor lock-in, and rigid pricing models. For enterprise workloads requiring rapid, large-scale deployment of Virtual Private Servers (VPS), a multi-cloud strategy balances cost efficiency and high availability. Hetzner Online delivers unmatched raw compute performance per dollar in European and North American regions, while DigitalOcean offers a highly resilient global footprint with developer-friendly networking primitives.

However, orchestrating infrastructure across disparate providers manually introducing operational bottlenecks and human error. This technical guide demonstrates how to achieve unified, automated bulk provisioning across both Hetzner and DigitalOcean using OpenTofu—the open-source, community-driven evolution of Terraform—integrated seamlessly into a continuous delivery pipeline via GitHub Actions.

Why OpenTofu? Navigating the Post-Bsl Infrastructure Landscape

Following the licensing shift of HashiCorp Terraform to a Business Source License (BSL), the cloud-native ecosystem required a strictly open-source, community-governed alternative. OpenTofu fills this void under the stewardship of the Linux Foundation. It retains 100% backward compatibility with existing Terraform registries, modules, and syntax, while introducing performance optimizations and a commitment to open-source innovation.

By adopting OpenTofu for multi-cloud deployments, enterprises secure several operational advantages:

• Zero License Risks: Full adherence to true open-source paradigms, ensuring no sudden compliance or operational cost overheads.
• Native Provider Compatibility: Seamlessly utilizes official Hetzner (hcloud) and DigitalOcean (digitalocean) providers without modification.
• Declarative State Management: Guarantees that the desired infrastructure state matches actual cloud realities, automatically resolving drift.

Architectural Overview: Declarative Bulk Provisioning

To provision virtual servers in bulk efficiently, we leverage OpenTofu’s meta-arguments, specifically for_each and count. Instead of duplicating resource blocks for each virtual machine, we define a structured data map containing server characteristics (such as region, specifications, and OS images). The open-source engine iterates through this map dynamically, generating instances in parallel.

The architecture consists of three fundamental pillars:

1. The OpenTofu Configuration: Declarative files defining provider credentials, network topologies, firewall rules, and the target VPS matrices.
2. Remote State Storage: A secure, central repository for the OpenTofu state file (e.g., using an S3-compatible bucket with state locking) to maintain collaborative integrity.
3. The CI/CD Engine (GitHub Actions): An automated pipeline triggered by Git events (pull requests or merges to the main branch) that validates, plans, and applies infrastructure updates without local administrative execution.

Security Architecture Note: Production environments must never store API tokens or private SSH keys within the version control system. GitHub Actions encrypted secrets serve as the secure vector injection for cloud credentials at runtime.

Step-by-Step Blueprint: Configuring OpenTofu for Bulk Deployment

1. Defining Providers and Variables

First, initialize the required providers within a providers.tf file. We declare both hcloud and digitalocean, ensuring the engine fetches the correct binary plugins during initialization.

terraform {
  required_version = ">= 1.6.0"
  required_providers {
    hcloud = {
      source  = "hetznercloud/hcloud"
      version = "~> 1.45.0"
    }
    digitalocean = {
      source  = "digitalocean/digitalocean"
      version = "~> 2.30.0"
    }
  }
}

Next, abstract the server configurations into a structured map variable within variables.tf. This allows administrative teams to add or remove servers simply by editing a JSON or HCL map file, separating configuration logic from execution definitions.

2. Implementing the Bulk Resource Logic

Using the for_each block allows for granular specification per instance. Below is an abstract conceptual representation of provisioning multiple Hetzner cloud servers using an iterative map:

By mapping configurations dynamically, you can simultaneously specify cx21 instances in Falkenstein (FZ) and cpx31 instances in Hillsboro (HEL) within a single structural block. The identical logic applies to the DigitalOcean droplet definitions, referencing the digitalocean_droplet resource type.

Integrating GitHub Actions for GitOps Automation

With the declarative configuration established, the next milestone is shifting execution away from local terminal environments to an automated, auditable continuous deployment pipeline via GitHub Actions.

Pipeline Workflow Architecture

A production-ready pipeline enforces a rigorous peer-review mechanism via two distinct stages:

• Pull Request (Plan Phase): When a developer updates the infrastructure configuration, GitHub Actions executes tofu plan. This generates a speculative execution plan showing exactly what resources will be created, modified, or destroyed, outputting the diff directly to the PR comments.
• Merge to Main (Apply Phase): Once approved and merged, the pipeline executes tofu apply, pushing the changes to the cloud APIs and modifying infrastructure in real time.

Configuring the GitHub Actions Workflow File

Create a workflow file at .github/workflows/tofu-deploy.yml. The workflow defines environment variables mapped from GitHub Repository Secrets, ensuring high-grade cryptography shields critical administrative access tokens:

name: "OpenTofu Multi-Cloud Deployment"

on:
  push:
    branches:
      - main
  pull_request:

jobs:
  opentofu:
    name: "OpenTofu Execution"
    runs-on: ubuntu-latest
    env:
      HCLOUD_TOKEN: ${{ secrets.HCLOUD_TOKEN }}
      DIGITALOCEAN_TOKEN: ${{ secrets.DIGITALOCEAN_TOKEN }}
    steps:
      - name: Checkout Code
        uses: actions/checkout@v4

      - name: Setup OpenTofu
        uses: opentofu/setup-opentofu@v1
        with:
          tofu_version: 1.7.2

      - name: OpenTofu Init
        run: tofu init

      - name: OpenTofu Validate
        run: tofu validate

      - name: OpenTofu Plan
        id: plan
        if: github.event_name == 'pull_request'
        run: tofu plan -no-color

      - name: OpenTofu Apply
        if: github.ref == 'refs/heads/main' && github.event_name == 'push'
        run: tofu apply -auto-approve

Best Practices for Scale, State, and Concurrency

When orchestrating dozens or hundreds of virtual servers concurrently, infrastructure teams must implement specific mitigation strategies to ensure system stability and security:

1. Implement Distributed State Locking

If multiple engineers or pipeline runners attempt to execute configurations simultaneously, state corruption can occur. Utilizing an external backend like HashiCorp Consul, AWS S3 with DynamoDB locking, or Gitlab Managed Terraform State ensures that a global execution lock is maintained during updates.

2. Rate Limiting and Cloud Provider Quotas

Bulk provisioning triggers dozens of concurrent API calls. Both Hetzner and DigitalOcean enforce strict API rate limits and initial account resource quotas. If your automation provisions more than 10 to 20 instances simultaneously, contact the respective support channels to increase your subscription limits prior to launch, or use the OpenTofu parallelization flag (-parallelism=n) to limit concurrent API operations.

3. Standardized Cloud-Init Bootstrapping

Provisioning hardware is only half the battle. To ensure these bulk instances are ready for production, leverage the user_data parameter to inject Cloud-Init scripts. These scripts automatically run system updates, inject administrator SSH public keys, establish base firewall configurations, or install monitoring agents (such as Prometheus node_exporter) immediately upon instance startup.

Conclusion: Unleashing Multi-Cloud Agility

By combining the open-source resilience of OpenTofu with the structured automation of GitHub Actions, infrastructure teams eliminate manual provisioning delays, configuration drift, and vendor dependencies. Whether bootstrapping a distributed computing cluster, establishing widespread edge nodes, or launching multi-regional development environments, this automated framework provides a robust, predictable, and fully auditable foundational layer for modern business enterprises.