# opentofu Published articles for opentofu. This is one page of public article previews, not the complete archive. Follow Next page to continue. Summaries are not the original full articles. ## Implementing GitOps from Infrastructure to DB Operators to Unify Ops for Kubernetes Databases DevFeed: [Implementing GitOps from Infrastructure to DB Operators to Unify Ops for Kubernetes Databases]() Original publisher: [Read original article]() Author: Sucahyo Ardy Prasetiyo Published: 2026-09-16T08:57:10Z Content type: tutorial Language: en Sources: [SeveralNines]() Topics: [GitOps](), [Kubernetes](), [Terraform](), [argo-cd](), [ClusterControl](), [Databases](), [opentofu]() Tags: [argo-cd](), [clustercontrol](), [databases](), [gitops](), [hybrid-operations](), [infrastructure](), [kubernetes](), [opentofu](), [sovereign-dbaas](), [terraform]() ### AI overview This article describes a layered GitOps approach for Kubernetes database platforms: manage infrastructure with Terraform or OpenTofu, manage Kubernetes deployments with Argo CD, and standardize operations for operator-managed databases with ClusterControl. It explains how declarative configuration and drift reconciliation differ between Terraform and Argo CD, and compares infrastructure automation options including Atlantis and Flux tf-controller. ### Source excerpt Most platform teams already use GitOps for their Kubernetes apps. The config lives in Git, Argo CD applies it, and deployments are predictable. But look one layer down and things get messy. Infrastructure setup is often still done by hand, running Terraform locally or through scattered scripts. Database operations, especially for databases running through Kubernetes [...] The post Implementing GitOps from Infrastructure to DB Operators to Unify Ops for Kubernetes Databases appeared first on Severalnines. ## Harness shipped 58 features in August 2026, including AI code review and agent security scanning DevFeed: [Harness shipped 58 features in August 2026, including AI code review and agent security scanning]() Original publisher: [Read original article]() Author: Chinmay Gaikwad Published: 2026-09-02T18:04:00Z Content type: release Language: en Sources: [Harness Blog]() Topics: [Artificial Intelligence](), [AI-assisted coding](), [AI Agent](), [Code review](), [prompt injection](), [Security](), [Terraform]() Tags: [2026](), [ai-code-review](), [code-review](), [coding-agents](), [opentofu](), [prompt-injection](), [security](), [terraform]() ### AI overview Harness describes 58 features released in August 2026, including an agent-scale code repository, AI Code Review, AI Risks scanning for prompt injection and tool poisoning in agent skills, and risk scoring for Terraform and OpenTofu changes. ### Source excerpt Harness shipped 58 features in August 2026: an agent-scale code repository, AI Code Review, AI Risks scanning, and the Blast Radius Agent. | Blog ## 9 things to consider before choosing an IaC platform in 2026 DevFeed: [9 things to consider before choosing an IaC platform in 2026]() Original publisher: [Read original article]() Author: Jonah Kowall Published: 2026-08-26T14:33:56Z Content type: article Language: en Sources: [Platform Engineering Blog]() Topics: [Infrastructure as code](), [Architecture & Design](), [Provisioning](), [Cloud](), [Terraform]() Tags: [2026](), [ci](), [cloud](), [evaluation](), [iac](), [infrastructure](), [infrastructure-as-code](), [opentofu](), [policy](), [terraform](), [workflows]() ### AI overview This 2026 article presents nine considerations for evaluating an infrastructure as code platform. It emphasizes that mature IaC now involves coordinating changes, managing access, enforcing policies, reviewing infrastructure changes, and keeping environments synchronized--not only provisioning cloud resources. It recommends assessing whether a platform is necessary, examining its execution layer and scalability, testing it under concurrent workloads and failures, and ensuring that engineers beyond the platform builder can use it effectively. ### Source excerpt IaC platform evaluation in 2026: nine things to test, from execution and dependency handling to policy enforcement, support quality and AI workflows. ## Best Kubernetes Infrastructure as Code Tools in 2026 DevFeed: [Best Kubernetes Infrastructure as Code Tools in 2026]() Original publisher: [Read original article]() Author: Pulumi Content Team Published: 2026-08-14T00:00:00Z Content type: comparison Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [Kubernetes](), [Terraform](), [argo-cd](), [Helm charts](), [GitOps](), [flux](), [opentofu](), [Amazon EKS](), [AWS CloudFormation](), [VPC](), [AWS IAM]() Tags: [argo-cd](), [cloudformation](), [code](), [comparisons](), [devops](), [flux](), [general](), [gitops](), [helm](), [helm-charts](), [iam](), [infrastructure](), [infrastructure-as-code](), [kubernetes](), [opentofu](), [platform-engineering](), [terraform](), [vpc]() ### AI overview This comparison explains that Kubernetes infrastructure as code spans cluster and cloud provisioning, in-cluster workload definition, and continuous delivery and reconciliation. It presents Pulumi and Terraform or OpenTofu as general-purpose provisioning options, Helm and Kustomize for workload templating, and Argo CD and Flux for GitOps reconciliation. ### Source excerpt There is no single best Kubernetes infrastructure as code tool, because "Kubernetes IaC" actually spans three different jobs. For provisioning the cluster and its cloud dependencies, Pulumi and Terraform (or OpenTofu) are the strongest general-purpose options. For templating and packaging workloads, Helm and Kustomize dominate. For continuous reconciliation once things are running, Argo CD and Flux lead the GitOps category. The right stack usually combines one tool from each layer, not a single tool that claims to do all three. What counts as infrastructure as code for Kubernetes? Kubernetes infrastructure as code work splits into three layers that get conflated constantly, and the confusion is where most tool comparisons go wrong. The cluster and cloud layer provisions the things Kubernetes itself sits on top of: the managed control plane (EKS, GKE, AKS), node pools, the VPC and subnets, IAM roles, load balancers, and cluster add-ons. Terraform, Pulumi, and cloud-native tools like CloudFormation operate here. The in-cluster workload layer defines what runs on the cluster once it exists: Deployments, Services, ConfigMaps, CustomResourceDefinitions, and the Helm charts or Kustomize overlays that template them. This is where Helm, Kustomize, and Crossplane's custom resources live. The delivery and reconciliation layer keeps what's declared in Git in sync with what's actually running on the cluster, continuously, rather than as a one-shot apply. Argo CD and Flux own this layer, and they consume the output of the other two rather than replacing them. Most real Kubernetes platforms use tools from at least two of these layers together. A team might provision EKS with Terraform, package its application with Helm, and let Argo CD reconcile it continuously. Knowing which layer a tool actually addresses, rather than treating "Kubernetes IaC" as one shopping list, is the first decision that matters. Pulumi provisions the cluster and the workloads on it in the same language Pul ## Compatibility Testing Pulumi HCL DevFeed: [Compatibility Testing Pulumi HCL]() Original publisher: [Read original article]() Author: Ian Wahbe Published: 2026-08-14T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Testing](), [opentofu](), [Terraform](), [terraform provider](), [Code]() Tags: [code](), [engineering](), [hcl](), [opentofu](), [terraform](), [terraform-provider](), [testing]() ### AI overview The article explains a compatibility-testing approach for Pulumi HCL. It defines correctness as Pulumi HCL and OpenTofu generating the same Terraform provider steps from the same HCL program, then describes tests that compare provider configuration and RPC behavior. ### Source excerpt Pulumi HCL has at its core a simple promise: A program that works for tofu apply will also work for pulumi up. This must be true to allow Terraform modules to be shared between tofu config and Pulumi programs. This property makes testing Pulumi HCL simple. Let me explain. At the end of the day, Pulumi is a system to translate actual state & desired state into a series of imperative actions, so actual state can be reconciled to desired state. Terraform is a system to translate actual state & desired state into a series of imperative actions, so actual state can be reconciled to desired state. How desired state is expressed can be radically different, and the underlying reconciliation engine can be radically different, but at the end of the day, both tools do the same thing: Executing a Terraform program looks like this: flowchart LR tf["*.tf files"] current["current state"] subgraph engine["reconciliation engine"] direction LR desired["desired state"] --> internal["provider steps"] end output["provider steps"] tf --> desired current --> engine engine --> output Executing a Pulumi program is more dynamic, because the reconciliation engine is in more active dialog with the user's program. That said, the diagram is the same shape. To match semantics, Pulumi HCL dynamically bridges any Terraform provider in the registry. This means that, for the subset of Pulumi programs that are valid OpenTofu programs, both programs take the same input (*.tf files) and produce the same step output (Terraform provider steps). Providers are the part of our model that generates user-observable behavior, which means if we match what providers see, we match what users see. This gives us a really nice definition of correctness for Pulumi HCL1: Pulumi HCL correctly interprets an HCL program when it generates the same set of provider steps as tofu does. If you are familiar with property-based testing, you might be thinking this looks like a testable property. You're right. How we compatibility ## Pulumi Cloud Adds Terraform Backend Support for Agentic Infrastructure DevFeed: [Pulumi Cloud Adds Terraform Backend Support for Agentic Infrastructure]() Original publisher: [Read original article]() Author: Daniel Perlovsky Published: 2026-08-04T00:00:00Z Content type: release Language: en Sources: [Pulumi]() Topics: [Terraform](), [Infrastructure as code](), [opentofu](), [Cloud](), [Deployment]() Tags: [agentic](), [agents](), [ai-agents](), [cloud](), [deployment](), [enterprise](), [hcl](), [iac](), [infrastructure-as-code](), [opentofu](), [platform](), [product](), [pulumi-cloud](), [terraform]() ### AI overview Pulumi announces general availability of Pulumi Cloud as a backend for Terraform state. The release supports existing Terraform deployment patterns while adding Pulumi Cloud capabilities such as remote runs, visibility, manual approvals, and scalable access management. ### Source excerpt At Pulumi, we are building the platform for agentic infrastructure. Pulumi Cloud provides the guardrails and enterprise readiness needed to safely move fast in this new era. While we are seeing extraordinary adoption -- over 40% of our users now manage infrastructure using AI agents -- we know many organizations are at different phases in their AI journey and have to balance building for the future with maintaining their existing infrastructure as code (IaC) solutions like Terraform. Today, we are launching three ways that Pulumi lets you avoid trading off building for the future against building for today. You don't have to rip out Terraform to enter the agentic era. Pulumi Cloud brings agentic infrastructure to the IaC estate you already have. What we're shipping today Last December, our CEO Joe Duffy laid out his vision to make Pulumi the platform for all of your infrastructure as code. The capabilities we are launching today make that promise a reality. Pulumi is now fully interoperable with Terraform and OpenTofu and enables organizations to build upon their existing IaC estate rather than starting from scratch as they work toward the agentic infrastructure future. Pulumi Cloud as a Terraform backend We are excited to announce the general availability of Pulumi Cloud as the backend to your Terraform state, enabling organizations to seamlessly lift and shift their existing Terraform estates. We recognize there is lots of infrastructure that works as is, and switching over to a new management paradigm may not always be possible. Pulumi Cloud support for the Terraform state backend lets organizations maintain their existing Terraform deployment patterns while also unlocking the power of Pulumi Cloud. The following common patterns for running Terraform are now supported: Plans and applies run remotely by default for new Terraform stacks, following the behavior of HCP Terraform and Terraform Enterprise. When you run a Terraform operation, it executes on a Pulumi-hoste ## Emulating Terraform on Pulumi's Engine DevFeed: [Emulating Terraform on Pulumi's Engine]() Original publisher: [Read original article]() Author: Ian Wahbe Published: 2026-08-04T00:00:00Z Content type: article Language: en Sources: [Pulumi]() Topics: [Terraform](), [opentofu](), [terraform provider](), [configuration]() Tags: [engineering](), [hcl](), [modules](), [opentofu](), [protocol](), [providers](), [pulumi](), [terraform](), [terraform-provider](), [translation]() ### AI overview This article explains how Pulumi's HCL interpreter maps Terraform configuration, resources, providers, and modules onto the Pulumi engine. It reports that the implementation works with 96% of Pulumi's top Terraform modules and describes how Pulumi's terraform-provider relays between Pulumi and Terraform provider protocols. ### Source excerpt The core promise of Pulumi's HCL support is that you can bring your existing Terraform configuration and modules, and pulumi will run them. If it works in OpenTofu and doesn't work in Pulumi, we would like to fix that. Given that goal, our HCL interpreter needs to take HCL as input and emit instructions to the Pulumi engine that semantically match how tofu would interpret the same input. This is made harder by the fact that Pulumi and OpenTofu have fundamentally different engine semantics and provider ecosystems. This blog post will explore how we have implemented that mapping well enough to get 96%1 of our top Terraform modules working on Pulumi. We'll briefly walk through how Pulumi's HCL interpreter handles Terraform's resource semantics, providers, and modules. It will also call out where Pulumi's HCL support lets you do things that Terraform and OpenTofu will not allow. Providers Both Pulumi and Terraform have providers, but they don't have the same providers. While there are providers that Terraform does not have, Pulumi can always resolve a Terraform provider using Pulumi's confusingly named terraform-provider provider.2 This is the same provider that lets you consume Any Terraform Provider in another Pulumi program with pulumi package add terraform-provider .... The terraform-provider provider acts as a relay: it speaks Pulumi's protocol to the Pulumi engine, and speaks Terraform's provider protocol to the Terraform provider it stands up. Because Pulumi HCL needs to work with all Pulumi providers and because terraform-provider lets Pulumi HCL speak to Terraform providers via the Pulumi protocol, Pulumi HCL actually only speaks Pulumi protocols directly: flowchart LR subgraph n2Entry[" "] n2["terraform-provider"] end subgraph providerBox["Pulumi Provider"] direction TD n2Entry n3["Terraform Provider"] end n0["Pulumi HCL"] <--> n1["Pulumi Engine"] n1 <--> n2Entry n2 <--> n3 n2@{ shape: rect} n3@{ shape: rect} n0@{ shape: rect} n1@{ shape: rect} style n2Entry f ## A guided tour of Terraform state, hosted modules, and HCL in Pulumi DevFeed: [A guided tour of Terraform state, hosted modules, and HCL in Pulumi]() Original publisher: [Read original article]() Author: Christian Nunciato Published: 2026-08-04T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Terraform](), [opentofu](), [Amazon S3](), [Command-line interface](), [Cloud](), [GitHub](), [Template]() Tags: [amazon-s3](), [aws](), [cli](), [github](), [hcl](), [how-to](), [infrastructure-as-code](), [modules](), [opentofu](), [pulumi-cloud](), [registry](), [s3](), [terraform](), [tutorials]() ### AI overview A hands-on walkthrough shows how to move a Terraform project that provisions an Amazon S3 bucket into Pulumi Cloud. It covers Pulumi Cloud as a Terraform state backend, hosted Terraform modules, and HCL authoring support, with references to OpenTofu and AWS. ### Source excerpt Today's big release contains a whole new set of features designed for seamless interoperability with the Terraform and OpenTofu ecosystems, and there's a lot there -- so much that it can be tough to get your head around all of it. But it generally falls into three major categories: Support for Pulumi Cloud as a Terraform state backend, including remote execution with human approvals A Terraform module registry in Pulumi Cloud that lets you publish, document, and share your modules even across language boundaries First-class support for HCL as an authoring language in the Pulumi engine To make this release a little easier to appreciate holistically, I've put together a quick end-to-end walkthrough that doesn't quite cover everything, but does cover the big stuff, and should give you a sense of how it all comes together. We'll start with a simple Terraform project that you'll deploy to AWS, and then one step at a time, bring it into Pulumi Cloud and kick the tires on each of these new features as we go. It'll take a bit, but all you'll need are a free Pulumi account and the ability to deploy an S3 bucket to AWS. We've got a bunch to cover, so let's jump right in. Start with a Terraform project Our tour begins with a tiny Terraform project that provisions a single Amazon S3 bucket using a locally defined module that we'll publish later. The project is available on GitHub as a template, and the easiest way to use it is with the GitHub CLI: $ gh repo create my-tf-project \ --template cnunciato/simple-tf-template \ --public \ --clone && cd my-tf-project We'll use the local Terraform backend to start. Set your AWS credentials (preferably with environment variables), then deploy the project with Terraform or OpenTofu. (This walkthrough uses the terraform CLI, but you can swap in tofu if that's your preference.) $ terraform init && terraform apply ... Apply complete! Resources: 2 added, 0 changed, 0 destroyed. Outputs: bucket_arn = "arn:aws:s3:::my-tf-project-bucket-14d19ece" ## Terraform vs OpenTofu: Which IaC tool fits your platform strategy? DevFeed: [Terraform vs OpenTofu: Which IaC tool fits your platform strategy?]() Original publisher: [Read original article]() Author: Mallory Haigh Published: 2026-07-23T05:40:01Z Content type: article Language: en Sources: [Platform Engineering Blog]() Topics: [Infrastructure as code](), [Terraform](), [Platform Engineering](), [Provisioning](), [Open Source](), [configuration](), [Encryption]() Tags: [governance](), [hashicorp](), [iac](), [infrastructure-as-code](), [multi-cloud](), [open-source](), [opentofu](), [orchestration](), [platform-engineering](), [provisioning](), [strategy](), [terraform]() ### AI overview This guide compares Terraform and OpenTofu as infrastructure-as-code tools. It explains how HashiCorp's 2023 license change led to OpenTofu's creation as a Linux Foundation-governed fork, and frames the choice around platform engineering strategy, governance, licensing, state encryption, and long-term risk. ### Source excerpt HashiCorp's license change sparked the Terraform vs OpenTofu debate. Compare governance, licensing (BSL vs MPL 2.0), state encryption, and strategic fit for your platform engineering strategy. ## Best Terraform Alternatives in 2026 DevFeed: [Best Terraform Alternatives in 2026]() Original publisher: [Read original article]() Author: Pulumi Content Team Published: 2026-07-18T00:00:00Z Content type: comparison Language: en Sources: [Pulumi]() Topics: [Terraform](), [Infrastructure as code](), [opentofu](), [AWS CloudFormation](), [Platform Engineering](), [Artificial Intelligence](), [AI-assisted coding]() Tags: [2026](), [ai](), [ai-coding-agents](), [alternatives](), [devops](), [general](), [infrastructure-as-code](), [opentofu](), [platform-engineering](), [terraform]() ### AI overview A comparison of Terraform alternatives in 2026, including general-purpose-language platforms, HCL-compatible forks such as OpenTofu, and cloud-specific tools. It explains how licensing changes, HCL's limits for abstraction and testing, and AI coding agents are influencing infrastructure decisions. ### Source excerpt The strongest Terraform alternatives in 2026 fall into three groups: general-purpose-language platforms like Pulumi and AWS CDK, HCL-compatible forks like OpenTofu, and cloud-specific tools like AWS CloudFormation, Azure Bicep, and Crossplane. Which one fits depends less on syntax preference than on how well it lets your team, and your AI coding agents, read, test, and change infrastructure safely. What's changed since this list was last useful: HashiCorp archived CDK for Terraform in December 2025, OpenTofu shipped its 1.12 release in May 2026, and Pulumi now runs the same HCL files Terraform does, so authoring format and deployment engine are separate decisions. Why teams are re-evaluating Terraform in 2026 Terraform has been the default infrastructure-as-code tool for most of the last decade, and for good reason: a mature provider ecosystem, a large community, and a state model that most platform teams have learned to live with. But three forces are pushing teams to look again at what else is available. The first is licensing. HashiCorp moved Terraform from the open-source Mozilla Public License to the Business Source License in August 2023, a shift that triggered the community fork now known as OpenTofu. HashiCorp itself became a wholly owned subsidiary of IBM when that acquisition closed in February 2025. Neither event breaks anything for existing Terraform users, but both changed how governance and long-term product direction get decided, and that's enough for some platform teams to want a documented Plan B. The second is the accumulated cost of working in a domain-specific language. HCL wasn't designed for the abstraction, composition, and testing patterns that platform engineering now expects: sharing logic across teams, writing meaningful unit tests, and building internal libraries that read like software rather than templated configuration. Terraform has closed some of this gap over time, adding a native test framework in version 1.6, but the ceiling on wh ## Best Infrastructure as Code (IaC) Tools for 2026 DevFeed: [Best Infrastructure as Code (IaC) Tools for 2026]() Original publisher: [Read original article]() Author: Isaac Harris Published: 2026-07-05T00:00:00Z Content type: tutorial Language: en Sources: [Pulumi]() Topics: [Infrastructure as code](), [Provisioning](), [Terraform](), [opentofu](), [Software Engineering](), [Programming](), [AWS CloudFormation](), [Development]() Tags: [2026](), [aws](), [aws-cloudformation](), [azure](), [devops](), [general](), [google-cloud](), [iac](), [infrastructure-as-code](), [kubernetes](), [opentofu](), [programming](), [provisioning](), [pulumi](), [software-engineering](), [terraform]() ### AI overview A 2026 guide compares infrastructure as code tools including Pulumi, Terraform, OpenTofu, AWS CDK, AWS CloudFormation, Azure tools, Google Cloud Infrastructure Manager, Kubernetes YAML, and Crossplane. It discusses their approaches, licensing, pricing, AI-agent readiness, and tradeoffs, while explaining how IaC applies software engineering practices such as version control, testing, code review, and CI/CD to infrastructure management. ### Source excerpt The best infrastructure as code (IaC) tools in 2026 are Pulumi, Terraform, OpenTofu, AWS CDK, AWS CloudFormation, Azure ARM, Azure Bicep, Google Cloud Infrastructure Manager, Kubernetes YAML, and Crossplane. Each takes a different approach to defining and provisioning infrastructure, from general-purpose programming languages to declarative templates, and each carries distinct licensing, pricing, and AI-agent readiness tradeoffs worth weighing before you commit. Pulumi's own package registry lists hundreds of packages -- first-party providers, bridged Terraform providers, and community components -- illustrating how far multi-cloud coverage has expanded across the ecosystem. Since this post was published, Pulumi has added first-class support for HashiCorp Configuration Language (HCL). You can now write Pulumi programs in HCL directly, alongside general-purpose languages like TypeScript, Python, Go, and C#. To see how it works, see Pulumi HCL. As infrastructure complexity grows, teams increasingly seek approaches that provide the same developer productivity tools they use for application development. While template-based and domain-specific language approaches serve many use cases effectively, teams with complex requirements or programming backgrounds often find that general-purpose programming languages offer advantages in testing, abstraction, and collaboration. This comprehensive guide examines the most effective infrastructure as code tools available today, providing detailed analysis of core IaC platforms, complementary tools, and related technologies through the lens of software engineering best practices. Whether you're starting fresh with IaC or evaluating alternatives to overcome limitations in your current toolchain, we'll help you navigate this complex landscape and choose solutions that truly bring software engineering to infrastructure. Ready to try one of these approaches yourself? Get started with Pulumi for free and provision your first resource in minu ## Opentofu + Tailscale = Bootstrapped DevOps environment with VPN DevFeed: [Opentofu + Tailscale = Bootstrapped DevOps environment with VPN]() Original publisher: [Read original article]() Published: 2026-01-17T21:28:46Z Content type: tutorial Language: en Sources: [Personal blog of Anurag Bhatia]() Topics: [opentofu](), [tailscale](), [DevOps](), [Virtual Private Network](), [Deployment](), [Cloud](), [Server](), [Terraform]() Tags: [cloud](), [deployment](), [devops](), [hetzner](), [opentofu](), [tailscale](), [terraform](), [vpn]() ### AI overview The article demonstrates using OpenTofu with Tailscale to bootstrap a private network across development VMs. It presents configuration for deploying three IPv6-only servers and installing Tailscale with cloud-init, while noting that the approach is intended mainly for quick testing rather than permanent production servers. ### Source excerpt For the last few days, I have been playing with OpenTofu. For those who may not know, it's a fork of last Terraform as Terraform's license was changed due to IBM's acquisition of Hashicorp and is a Cloud Native Foundation project. It can be used to quickly deploy (and remove) resources from various cloud players. Yesterday came across this tweet from Tailscale about tailscale's module for deployment. Cloud-init can be tough, and we've heard all about it. So we built an open-source Terraform module, one that helps provide a more consistent Tailscale experience across AWS, Azure, GCP, and everywhere. No more surprises, OS quirks, or other mysteries: https://t.co/vn1ITU7Fgz pic.twitter.com/stcF6WuiD7 -- Tailscale (@Tailscale) January 15, 2026 It's cool and useful, though I find Cloud init way more useful since for me these tools are more useful for quick testing rather than a permanent production server. The idea of tailscale on devops VMs as they come up is pretty powerful, as it takes care of the private network between these machines, plus underlay doesn't matter, and hence one can use (cheaper) IPv6-only VMs. An example of OpenTofu config (which is similar to Terraform) to deploy three IPv6 only servers on players like Hetzner across Nuremberg, Helsinki, and Ashburn: main.tf terraform { required_providers { hcloud = { source = "hetznercloud/hcloud" version = "~> 1.59.0" } } } provider "hcloud" { token = var.hcloud_token } data "hcloud_ssh_key" "desktop" { name = "desktop" } data "hcloud_image" "ubuntu" { name = "debian-13" most_recent = true } resource "hcloud_server" "vms" { for_each = var.vms name = each.key image = data.hcloud_image.ubuntu.id server_type = each.value.server_type location = each.value.location ssh_keys = [data.hcloud_ssh_key.desktop.id] user_data = <<-EOF #cloud-config package_upgrade: true packages: - curl runcmd: - curl -fsSL https://tailscale.com/install.sh | sh - tailscale up --authkey=${var.tailscale_authkey} --accept-routes EOF public_net { ## How to create reproducible ZIPs for AWS Lambda DevFeed: [How to create reproducible ZIPs for AWS Lambda]() Original publisher: [Read original article]() Author: Misha Shiryaev Published: 2025-08-28T09:44:47Z Content type: tutorial Language: en Sources: [ClickHouse Blog]() Topics: [AWS Lambda](), [CI/CD](), [Python](), [Terraform](), [Linux](), [macOS]() Tags: [aws-lambda](), [ci-cd](), [how-to](), [infrastructure](), [linux](), [macos](), [opentofu](), [python](), [terraform]() ### AI overview The article explains how ClickHouse created reproducible ZIP archives for Python-based AWS Lambda functions. It discusses stable file ordering, normalized modification times, excluding Python byte-code files, and avoiding operating-system differences by creating the archive with Python. The workflow is intended for CI/CD infrastructure managed with Terraform/OpenTofu and avoids extra artifact infrastructure such as S3. ### Source excerpt Lessons from making reproducible ZIPs for Python Lambdas in CI/CD with Terraform and OpenTofu. ## Using OpenTofu/Terraform to create a disposable Tails virtual machine DevFeed: [Using OpenTofu/Terraform to create a disposable Tails virtual machine]() Original publisher: [Read original article]() Author: Staf Wagemakers Published: 2025-06-22T06:37:00Z Content type: tutorial Language: en Sources: [stafwag Blog]() Topics: [opentofu](), [Infrastructure as code](), [virtualization](), [gnu linux]() Tags: [fosdem](), [infrastructure-as-code](), [libvirt](), [linux](), [linux-foundation](), [open-source](), [opentofu](), [tails](), [terraform](), [tor](), [virtual-machine](), [virtualization]() ### AI overview This tutorial explains how OpenTofu and Terraform can provision disposable environments and presents a Terraform/OpenTofu module for creating a virtual machine running the latest Tails version on libvirt. It also notes security considerations for running Tails in a virtual machine. ### Source excerpt OpenTofu Terraform or OpenTofu (the open-source fork supported by the Linux Foundation) is a nice tool to setup the infrastructure on different cloud environments. There is also a provider that supports libvirt. https://github.com/dmacvicar/terraform-provider-libvirt If you want to get started with OpenTofu there is a free training available from the Linux foundation: https://training.linuxfoundation.org/express-learning/getting-started-with-opentofu-lfel1009/ I also joined the talk about OpenTofu and Infrastructure As Code, in general, this year in the Virtualization and Cloud Infrastructure DEV Room at FOSDEM this year: https://fosdem.org/2025/schedule/event/fosdem-2025-6057-the-iac-tooling-multiverse-and-the-future-of-iac/ ## New Chainguard Images December 2024: Adoptium, AWX, CouchDB DevFeed: [New Chainguard Images December 2024: Adoptium, AWX, CouchDB]() Original publisher: [Read original article]() Published: 2025-01-16T00:00:00Z Content type: release Language: en Sources: [Chainguard: Unchained]() Topics: [Adoptium](), [openjdk](), [Ansible](), [Java](), [NoSQL](), [Open Source](), [Erlang](), [.NET MAUI](), [Process]() Tags: [adoptium](), [ansible](), [apache](), [awx](), [chainguard](), [chainguard-images](), [container-images](), [couchdb](), [erlang](), [helm](), [java](), [jdk](), [linkerd](), [net-11](), [nosql](), [open-source](), [opentofu]() ### AI overview Chainguard describes its December 2024 batch of 39 new Chainguard Images, highlighting images for Adoptium, AWX, and Apache CouchDB. The article notes FIPS-enabled variants and summarizes the intended uses and image characteristics. ### Source excerpt Chainguard released several new images in December 2024, including images for Adoptium, AWX, CouchDB, and others. Check out the full list.