#infrastructure-as-code — Public Fediverse posts

The Double-Edged Sword of Digital Freedom: The Risks of Infinito.Nexus with Native Tor Support

⚠️ Disclaimer

This article was generated entirely by artificial intelligence without editorial review.

To publish this analysis quickly, I deliberately chose to release it without manual editing or fact-checking. The purpose of this article is not to provide a polished technical specification, but to stimulate discussion about the societal, ethical, and security implications of the next generation of Infinito.Nexus with native Tor support.

Some technical assumptions, predictions, or conclusions may therefore be incomplete, inaccurate, or open to debate. They should be understood as informed analysis rather than verified fact.

The scenarios described in this article are intended to illustrate both the opportunities and the risks of increasingly accessible privacy-preserving infrastructure. They do not advocate, encourage, or endorse illegal activity. The same technologies that can strengthen digital sovereignty, protect journalists, human rights organizations, researchers, and political opposition operating under censorship can also be misused by malicious actors.

The goal of this article is to encourage an open discussion about the consequences of making powerful decentralized infrastructure available to a much broader audience. As with encryption, Linux, Git, peer-to-peer networks, and the Internet itself, technological progress creates both new freedoms and new responsibilities.

Please read this article critically, verify important claims independently, and view it as a starting point for discussion rather than a definitive statement on the future of decentralized infrastructure.

Technology is neutral.

Whether it empowers democratic resistance or enables organized crime depends on the people using it.

With native Tor integration, Infinito.Nexus has the potential to fundamentally change how self-hosted infrastructure is deployed. It could become possible for anyone to create a completely private digital ecosystem with only minimal technical knowledge.

That prospect is both exciting — and concerning.

A World Beyond Traditional Surveillance

Today’s Internet relies heavily on centralized infrastructure.

Governments can subpoena cloud providers.

Internet Service Providers can monitor traffic.

Hosting companies know where servers are located.

DNS providers can suspend domains.

Payment providers can freeze accounts.

Social media platforms can remove communities.

Tor changes that equation.

By integrating Tor directly into the infrastructure layer instead of treating it as an optional add-on, organizations could operate entirely within Onion Services.

No public IP addresses.

No public DNS.

No visible server locations.

No conventional attack surface.

Infrastructure that was previously easy to discover suddenly becomes practically invisible to anyone outside the Tor network.

From Old Smartphones to Invisible Infrastructure

Perhaps the most disruptive consequence of native Tor support is that almost anyone could become an anonymous infrastructure operator.

Instead of renting a VPS or purchasing expensive server hardware, users could simply take an old smartphone, install a Linux distribution such as Droidian, deploy Infinito.Nexus, and immediately have a functional server reachable exclusively through Tor.

Modern smartphones already contain everything traditionally required for a small server:

• multicore ARM processors
• flash storage
• Wi-Fi and LTE connectivity
• extremely low power consumption
• integrated batteries acting as an Uninterruptible Power Supply (UPS)

Unlike conventional servers, smartphones can continue operating during short power outages without requiring any additional hardware.

Because all communication occurs through Onion Services, the physical location of the device becomes significantly harder to determine than traditionally hosted infrastructure.

A server could operate from:

• an apartment
• an office
• a vehicle
• a backpack
• a cabin
• virtually anywhere with Internet access

Instead of racks in a datacenter, entire organizations could operate from inexpensive commodity hardware.

Infrastructure that once required thousands of dollars could eventually fit inside a jacket pocket.

Organization Beyond Censorship

Perhaps the most transformative consequence of native Tor support is not anonymity itself — it is organization.

Modern democratic movements require far more than encrypted messaging. They need complete digital infrastructure.

Imagine a group deploying the following services exclusively as Onion Services:

• Matrix for encrypted communication
• Nextcloud for document sharing
• OpenProject for task management
• Git for software development
• Wiki systems for documentation
• forums for public discussion
• video conferencing
• identity management with single sign-on

Every service is accessible only through Tor.

There are no public IP addresses.

There are no publicly reachable domains.

There is no central cloud provider that can simply terminate the infrastructure.

For political opposition movements operating under authoritarian governments, this could fundamentally change what is possible.

In countries such as Russia or Iran, governments have repeatedly attempted to restrict independent media, block communication platforms, and pressure hosting providers into taking services offline. A decentralized infrastructure based on Tor Onion Services makes these traditional forms of censorship considerably more difficult.

If one server disappears, another can be brought online using the same deployment automation and cryptographic identities.

Instead of relying on a single datacenter, an organization could distribute its infrastructure across many independently operated devices, including repurposed smartphones running Linux distributions such as Droidian. Every device becomes part of the organization’s digital backbone while remaining reachable only through the Tor network.

This significantly lowers the barrier to building resilient communication networks for journalists, NGOs, researchers, humanitarian organizations, and democratic opposition movements.

Building Invisible Organizations

Imagine an organization deploying:

• Identity Management
• Matrix
• Nextcloud
• Git
• Email
• Video Conferencing
• Project Management
• Forums
• Social Networks
• AI Infrastructure

Every service exists exclusively as an Onion Service.

Employees connect only through Tor.

No public domains.

No public IP addresses.

No externally visible services.

From the perspective of the public Internet, the organization barely exists.

A Powerful Tool for Democracy

For many people around the world, this would be an extraordinary step toward digital sovereignty.

Political opposition operating under authoritarian governments often faces:

• Internet censorship
• mass surveillance
• infrastructure seizures
• domain confiscation
• ISP monitoring
• targeted cyber attacks

A hidden smartphone consuming only a few watts of electricity could host secure communications for an activist movement.

Journalists could publish anonymously.

NGOs could coordinate without relying on commercial cloud providers.

Entire communities could communicate through infrastructure that is extremely difficult to discover or disable.

History repeatedly demonstrates that secure communication is one of the foundations of democratic resistance.

The Other Side of the Coin

Unfortunately, technology does not distinguish between good and bad actors.

The exact same infrastructure could also be deployed by:

• organized cybercrime
• ransomware groups
• illegal marketplaces
• extremist organizations
• terrorist networks
• large-scale fraud operations
• illegal trafficking

If deploying anonymous infrastructure becomes as simple as flashing Linux onto an old smartphone and clicking through an installation wizard, the barrier to entry changes dramatically.

What once required experienced Linux administrators could eventually become accessible to almost anyone.

A hidden smartphone server could host:

• a secure school collaboration platform

or

• an anonymous criminal marketplace.

Technically, there may be little difference.

The software cannot distinguish between them.

Risks for Democratic Societies

For democratic societies such as Germany, this presents a difficult challenge.

Security agencies often rely on information obtained from hosting providers, cloud operators, domain registries, DNS providers, or centralized communication platforms during investigations.

Infrastructure that exists exclusively as Tor Onion Services reduces the availability of these traditional investigative paths.

This can make investigations more difficult and more resource-intensive, especially when organizations are technically competent and operate their own infrastructure.

A terrorist cell, extremist group, or organized criminal network could theoretically operate:

• private Matrix servers
• encrypted file storage
• internal forums
• planning boards
• identity systems
• software repositories
• anonymous web services

all without relying on public-facing infrastructure.

That does not mean such groups become impossible to detect.

Tor does not make people invisible.

Law enforcement can still use endpoint forensics, undercover operations, financial investigations, human intelligence, surveillance of physical logistics, and mistakes made by suspects.

But the balance changes.

The stronger privacy technologies become, the harder traditional bulk surveillance and provider-based investigations become.

This is exactly why the same tools that protect dissidents in authoritarian states can also create serious challenges for law enforcement in democratic states.

The Democratization of Anonymous Infrastructure

Historically, operating Onion Services required substantial expertise.

Administrators needed to understand:

• Linux
• networking
• reverse proxies
• DNS
• Tor
• certificates
• firewalls
• application integration

Automation changes everything.

Eventually, the entire deployment process could become:

1. Install Droidian on an old smartphone.
2. Install Infinito.Nexus.
3. Select the desired applications.
4. Enable Tor support.
5. Click Deploy.

Minutes later, an entire private infrastructure could be online.

No cloud provider.

No VPS.

No static IP.

No public DNS.

Infrastructure that previously required experienced system administrators becomes accessible to ordinary users.

That democratization is both empowering and dangerous.

Open Source Has Always Faced This Dilemma

This is not a new ethical problem.

Encryption protects:

• journalists
• dissidents
• criminals

VPNs protect:

• activists
• ransomware operators

Git is used to build:

• medical software
• malware

Linux powers:

• hospitals
• botnets

Artificial Intelligence can:

• accelerate scientific discovery
• generate phishing campaigns

Technology itself has no morality.

People do.

Infinito.Nexus Is Infrastructure

Infinito.Nexus is not being developed to create hidden criminal networks.

Its purpose is to simplify the deployment of sovereign, self-hosted infrastructure.

Native Tor support simply extends that philosophy.

The software itself does not decide who uses it.

The responsibility remains with those who deploy it.

The Ethical Challenge

Should powerful privacy technologies be withheld because they could be abused?

Or should society accept that technologies capable of protecting freedom will inevitably also be exploited by malicious actors?

There is no perfect answer.

Throughout history, almost every revolutionary communication technology — from the printing press to encrypted messaging — has been used for both constructive and destructive purposes.

Tor is no different.

Neither is Infinito.Nexus.

Technical Design

Native Tor support is currently being designed as a core networking feature of Infinito.Nexus.

Instead of treating Tor as an optional add-on, every deployed application can automatically receive its own Onion Service while remaining fully integrated into the deployment framework.

The current design proposal is publicly available:

Native Tor Support Requirements
https://github.com/kevinveenbirkenbach/infinito-nexus-core/blob/feature/svc-net-tor/docs/requirements/031-svc-net-tor-onion.md

Related projects:

Infinito.Nexus Core
https://github.com/kevinveenbirkenbach/infinito-nexus-core

Hetzner Arch LUKS
https://github.com/kevinveenbirkenbach/hetzner-arch-luks

Linux Image Manager
https://github.com/kevinveenbirkenbach/linux-image-manager

These projects together lay the groundwork for a future where deploying fully encrypted, self-hosted, Tor-native infrastructure becomes almost as simple as installing a mobile app.

Conclusion

Native Tor support has the potential to fundamentally reshape how self-hosted infrastructure is deployed.

For the first time, individuals, NGOs, journalists, companies, and political opposition movements could build private digital ecosystems with remarkably little technical expertise.

At the same time, the same technology could lower the barrier for anonymous criminal infrastructure.

A discarded smartphone running Linux could become a resilient, battery-backed server hidden almost anywhere.

That reality is both inspiring and unsettling.

Like encryption, Linux, Git, VPNs, and the Internet itself, Infinito.Nexus is infrastructure.

Infrastructure does not decide how it is used.

People do.

The challenge for society is therefore not whether such technology should exist, but how we choose to live in a world where powerful privacy tools become accessible to everyone.

Unlocking Fully Encrypted Servers over Tor

Remote servers should not have to choose between security and availability.

For years, the common compromise has been to expose SSH to the public Internet or to rely on VPNs and provider-specific KVM consoles whenever a LUKS-encrypted server reboots.

I believe there is a better approach.

By combining LUKS, Tor Onion Services, and a lightweight SSH server running directly inside the initramfs, it is possible to build servers that remain fully encrypted at rest, yet can always be unlocked remotely without exposing any public management interface.

This article describes the concept and how it could evolve into a reusable feature for Infinito.Nexus.

The Problem

Full disk encryption protects data when a server is powered off.

However, after every reboot someone must enter the LUKS passphrase.

For remote dedicated servers this usually means one of the following:

• opening SSH to the Internet
• connecting through a VPN
• using a provider’s KVM/IPMI console
• booting into a rescue system

While remote unlocking via Dropbear inside the initramfs is already a well-known solution, it still typically relies on a publicly reachable IP address.

The Idea

Instead of exposing SSH publicly, start Tor directly inside the initramfs.

The boot sequence would look like this:

Server boots
        │
        ▼
Kernel + initramfs
        │
        ▼
Network initialization
        │
        ▼
Tor starts
        │
        ▼
Temporary Onion Service appears

unlock-xxxxxxxx.onion
        │
        ▼
SSH via Tor
        │
        ▼
cryptsetup luksOpen
        │
        ▼
Root filesystem unlocked
        │
        ▼
Operating system boots
        │
        ▼
Temporary Onion Service disappears

The administrator simply connects through Tor:

torsocks ssh [email protected]

After entering the LUKS passphrase, the operating system continues booting normally.

Separate Identities for Boot and Runtime

One of the strongest aspects of this design is that boot-time and runtime use different Onion identities.

Boot environment

• dedicated Ed25519 key
• dedicated Onion address
• only SSH
• exists only during boot

Example:

unlock-xxxxxxxx.onion

Runtime environment

Once the operating system has booted:

• the initramfs exits
• Tor inside initramfs stops
• a new Tor instance starts
• completely different Onion addresses become available

For example:

ssh-xxxxxxxx.onion
cloud-xxxxxxxx.onion
matrix-xxxxxxxx.onion
mail-xxxxxxxx.onion

The unlock address simply disappears.

This cleanly separates the trust boundaries between the bootloader environment and the running operating system.

Why Tor?

Using Tor instead of exposing SSH directly provides several advantages:

• no public IP address required
• no exposed SSH port
• no VPN infrastructure
• works behind NAT or Carrier-Grade NAT
• management interface is only reachable through the Tor network
• additional network privacy
• ideal for self-hosted infrastructure

This is particularly attractive for servers hosted in data centers where administrators rarely have physical access.

What Happens After a Crash?

Whenever the server reboots:

1. the initramfs starts
2. networking is initialized
3. Tor publishes the temporary Onion Service
4. you connect via SSH
5. you unlock LUKS
6. the server continues booting

No KVM console.

No VPN.

No public SSH endpoint.

Only Tor.

Of course, catastrophic failures such as a broken initramfs or missing network drivers still require traditional recovery methods such as a rescue system or KVM.

Existing Building Blocks

Most of the required components already exist today.

My repository hetzner-arch-luks demonstrates how to deploy Arch Linux with full disk encryption on Hetzner servers and configure remote unlocking via SSH during the initramfs stage.

Repository:

https://github.com/kevinveenbirkenbach/hetzner-arch-luks

Another project, linux-image-manager, automates the creation and customization of Linux images and could serve as the foundation for embedding Tor, Dropbear/TinySSH, and the required initramfs configuration into reusable images.

Repository:

https://github.com/kevinveenbirkenbach/linux-image-manager

Together, these repositories provide much of the groundwork required for a fully automated implementation.

Future Integration into Infinito.Nexus

I envision this becoming a native feature of Infinito.Nexus.

Provisioning a server could automatically:

• install Arch Linux
• configure LUKS full disk encryption
• generate an initramfs containing:
  • Tor
  • Dropbear or TinySSH
  • cryptsetup
• create a dedicated boot-time Onion Service
• automatically switch to permanent runtime Onion Services after successful boot

From the administrator’s perspective, recovering a rebooted server would be as simple as:

torsocks ssh root@unlock-<hostname>.onion

Enter the passphrase.

The server continues booting.

Nothing is ever exposed to the public Internet.

Looking Ahead

This concept combines three mature technologies:

• LUKS
• Tor Onion Services
• Remote initramfs unlocking

While each technology already exists independently, integrating them into a seamless provisioning workflow could significantly improve the security and usability of encrypted self-hosted infrastructure.

For projects focused on digital sovereignty and privacy, removing the need for publicly exposed management interfaces is a natural next step.

iX-Workshop: IT-Infrastrukturen mit OpenTofu aufbauen und verwalten

Erfahren Sie, wie Sie mit OpenTofu die IT-Infrastruktur im Unternehmen als Code definieren, bereitstellen und administrieren.

https://www.heise.de/news/iX-Workshop-IT-Infrastrukturen-mit-OpenTofu-aufbauen-und-verwalten-11343654.html?wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege&utm_source=mastodon

#Automatisierung #CloudComputing #InfrastructureasCode #IT #ITInfrastruktur #iXWorkshops #Linux #Rechenzentrum #news

iX-Workshop: IT-Infrastrukturen mit OpenTofu aufbauen und verwalten

Erfahren Sie, wie Sie mit OpenTofu die IT-Infrastruktur im Unternehmen als Code definieren, bereitstellen und administrieren.

https://www.heise.de/news/iX-Workshop-IT-Infrastrukturen-mit-OpenTofu-aufbauen-und-verwalten-11343654.html?wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege&utm_source=mastodon

#Automatisierung #CloudComputing #InfrastructureasCode #IT #ITInfrastruktur #iXWorkshops #Linux #Rechenzentrum #news

WHERE OTHERS LOSE CONTROL – WE STAY IN THE LOOP.

https://blog.infinito.nexus/blog/2026/06/16/where-others-lose-control-we-stay-in-the-loop/

Fragmented workflows built on manual handoffs are basically an operational risk waiting for the worst possible moment to break production. 🛡️

The challenge is not deciding to consolidate but executing the move without your teams feeling like they are losing all control.

Stop the cycle of shadow IT and start building a golden path that actually delivers on its promises. ⚡

👉 https://upsun.com/blog/migration-checklist-moving-from-fragmented-workflows-to-a-unified-platform/

#PlatformEngineering #CloudNative #DevOps #infrastructureascode

Fragmented workflows built on manual handoffs are basically an operational risk waiting for the worst possible moment to break production. 🛡️

The challenge is not deciding to consolidate but executing the move without your teams feeling like they are losing all control.

Stop the cycle of shadow IT and start building a golden path that actually delivers on its promises. ⚡

👉 https://upsun.com/blog/migration-checklist-moving-from-fragmented-workflows-to-a-unified-platform/

#PlatformEngineering #CloudNative #DevOps #infrastructureascode

If you want to trust your VM configurations, you need to automate variability and consistency, even when you get to enterprise scale. Puppet experts Stephen K Potter and Matthew Stone put together a solid breakdown of what makes VM configuration so challenging:

➡️ https://www.puppet.com/blog/vm-configuration

- You need to enforce state beyond day 0

- “Almost identical” VMs are where drift really start to show up

- Misconfiguration impacts performance and DevEx too

#Puppet #InfrastructureAsCode #DevOps

If you want to trust your VM configurations, you need to automate variability and consistency, even when you get to enterprise scale. Puppet experts Stephen K Potter and Matthew Stone put together a solid breakdown of what makes VM configuration so challenging:

➡️ https://www.puppet.com/blog/vm-configuration

- You need to enforce state beyond day 0

- “Almost identical” VMs are where drift really start to show up

- Misconfiguration impacts performance and DevEx too

#Puppet #InfrastructureAsCode #DevOps

Platform Engineering Labs has announced a major update to formae - its #opensource #IaC platform.

New capabilities include:
➤ Full Kubernetes support
➤ Native Helm integration
➤ Direct .tfvars compatibility
➤ A new public plugin hub

More details on #InfoQ ➤ https://bit.ly/4dM6hKC

#PlatformEngineering #DevOps #InfrastructureAsCode #Kubernetes #CloudNative

Platform Engineering Labs has announced a major update to formae - its #opensource #IaC platform.

New capabilities include:
➤ Full Kubernetes support
➤ Native Helm integration
➤ Direct .tfvars compatibility
➤ A new public plugin hub

More details on #InfoQ ➤ https://bit.ly/4dM6hKC

#PlatformEngineering #DevOps #InfrastructureAsCode #Kubernetes #CloudNative

"The question isn't whether #AI will replace #DevOps engineers. It's whether you understand your systems well enough to know when it's wrong. It will be wrong. And it won't tell you." - Heinan Cabouly

Companies in regulated industries such as #TDBank, #Vega and #EY are proceeding with caution with #AIagents for #InfrastructureasCode -- but proceeding nonetheless. And a new developer interface for IT automation might be taking shape...

Get all the details, including #Ansible by #RedHat 's approach to this shift, in my latest writeup here: https://www.techtarget.com/searchitoperations/news/366643426/IT-orgs-cautiously-try-AI-agents-for-infrastructure-as-code

"The question isn't whether #AI will replace #DevOps engineers. It's whether you understand your systems well enough to know when it's wrong. It will be wrong. And it won't tell you." - Heinan Cabouly

Companies in regulated industries such as #TDBank, #Vega and #EY are proceeding with caution with #AIagents for #InfrastructureasCode -- but proceeding nonetheless. And a new developer interface for IT automation might be taking shape...

Get all the details, including #Ansible by #RedHat 's approach to this shift, in my latest writeup here: https://www.techtarget.com/searchitoperations/news/366643426/IT-orgs-cautiously-try-AI-agents-for-infrastructure-as-code

From zero to production-ready infrastructure – with an Ansible playbook. 🛠️ In his blog post, Tim shows how you can automatically provision a complete environment using our Nine API and nctl. No manual dashboard clicking, everything reproducible, as code, and everything hosted in Switzerland. 🇨🇭 What does that mean? Fewer careless mistakes and faster setups. For more info and details, read the full article: 👉 https://nine.ch/en/blog/from-zero-to-infra-building-a-production-ready-setup-using-our-api-and-ansible/ #infrastructureascode #ansible #devops #automation #nine

From zero to production-ready infrastructure – with an Ansible playbook. 🛠️ In his blog post, Tim shows how you can automatically provision a complete environment using our Nine API and nctl. No manual dashboard clicking, everything reproducible, as code, and everything hosted in Switzerland. 🇨🇭 What does that mean? Fewer careless mistakes and faster setups. For more info and details, read the full article: 👉 https://nine.ch/en/blog/from-zero-to-infra-building-a-production-ready-setup-using-our-api-and-ansible/ #infrastructureascode #ansible #devops #automation #nine

#OpenTofu 1.12 is out!

This update isn’t a complete rewrite, but it does resolve some issues that infrastructure teams have faced for a while.

Find out more: https://bit.ly/3RY6AdU

#InfoQ #DevOps #Terraform #InfrastructureAsCode

#OpenTofu 1.12 is out!

This update isn’t a complete rewrite, but it does resolve some issues that infrastructure teams have faced for a while.

Find out more: https://bit.ly/3RY6AdU

#InfoQ #DevOps #Terraform #InfrastructureAsCode

Pipeline-as-truth creates invisible drift. Declare intended state in versioned configuration files and treat the pipeline as an executor, not an authority. https://hackernoon.com/your-automation-pipeline-is-not-a-source-of-truth #infrastructureascode

Pipeline-as-truth creates invisible drift. Declare intended state in versioned configuration files and treat the pipeline as an executor, not an authority. https://hackernoon.com/your-automation-pipeline-is-not-a-source-of-truth #infrastructureascode

Terraform for the VMs and Ansible for the config are already paying off.

I took my old Ansible playbook that initialized a cluster, joined the other control plane nodes, and then joined two workers which all still works.

Now the really fun part comes about configuring the cluster entirely with some tool, which I might go back to Terraform for. I know I'll want to configure a CNI to start, and kube-vip for the control plane nodes, then I'll be able to get some workloads going.

#homelab #kubernetes #ansible #terraform #infrastructureascode #pipelines

Terraform for the VMs and Ansible for the config are already paying off.

I took my old Ansible playbook that initialized a cluster, joined the other control plane nodes, and then joined two workers which all still works.

Now the really fun part comes about configuring the cluster entirely with some tool, which I might go back to Terraform for. I know I'll want to configure a CNI to start, and kube-vip for the control plane nodes, then I'll be able to get some workloads going.

#homelab #kubernetes #ansible #terraform #infrastructureascode #pipelines

I'm exploring how to handle the cluster creation now that I can provision nodes on demand and it seems to be the easiest way will be to use Ansible.

I already have a playbook for that (which is great) I'll just need to adjust it to the new inventory and configurations. Should be easy enough?

From there, I think I'll figure out how I want to deploy resources in some idempotent manner. This is where Terraform might come back into play.

I also want to work on testing new versions of containers in a dev space as well as restoring from backups for my more important data, but that's an issue for another month.

#homelab #kubernetes #terraform #ansible #infrastructureascode

I'm exploring how to handle the cluster creation now that I can provision nodes on demand and it seems to be the easiest way will be to use Ansible.

I already have a playbook for that (which is great) I'll just need to adjust it to the new inventory and configurations. Should be easy enough?

From there, I think I'll figure out how I want to deploy resources in some idempotent manner. This is where Terraform might come back into play.

I also want to work on testing new versions of containers in a dev space as well as restoring from backups for my more important data, but that's an issue for another month.

#homelab #kubernetes #terraform #ansible #infrastructureascode

OpenTofu continua a crescere come piattaforma Infrastructure as Code open source compatibile con Terraform. Nuove funzioni semplificano multi-cloud, sicurezza e gestione dei provider. #OpenTofu #Linux #DevOps #CloudComputing #Terraform #InfrastructureAsCode

https://www.linuxeasy.org/opentofu-automazione-sicurezza-gestione-cloud-semplificata/?utm_source=mastodon&utm_medium=jetpack_social

OpenTofu continua a crescere come piattaforma Infrastructure as Code open source compatibile con Terraform. Nuove funzioni semplificano multi-cloud, sicurezza e gestione dei provider. #OpenTofu #Linux #DevOps #CloudComputing #Terraform #InfrastructureAsCode

https://www.linuxeasy.org/opentofu-automazione-sicurezza-gestione-cloud-semplificata/?utm_source=mastodon&utm_medium=jetpack_social

Of course, things like this are easy with Terraform. Here’s an inventory/config, go make it. This post was more about avoiding sunk cost fallacy with clusterctl.

I even added Terraform configuring the DNS entries for the 5 nodes and figured that was enough for tonight.

#homelab #terraform #kubernetes #infrastructureascode #automation

Of course, things like this are easy with Terraform. Here’s an inventory/config, go make it. This post was more about avoiding sunk cost fallacy with clusterctl.

I even added Terraform configuring the DNS entries for the 5 nodes and figured that was enough for tonight.

#homelab #terraform #kubernetes #infrastructureascode #automation

Gave up on using clusterctl for the time being, figured out I can get a lot further with Terraform and the template from image-builder (with some minor modifications).

In just over an hour, I already have Terraform provisioning 5 empty VMs preinstalled with the software I need. I'm 99% sure there are ways to provision k8s clusters in Terraform so I don't need to reinvent that wheel. Here are 3 control plane nodes, and 2 worker nodes, go build it.

The only change I had to make with the image-builder template was to re-add a cloud-init disk.

#homelab #terraform #kubernetes #infrastructureascode #automation

Gave up on using clusterctl for the time being, figured out I can get a lot further with Terraform and the template from image-builder (with some minor modifications).

In just over an hour, I already have Terraform provisioning 5 empty VMs preinstalled with the software I need. I'm 99% sure there are ways to provision k8s clusters in Terraform so I don't need to reinvent that wheel. Here are 3 control plane nodes, and 2 worker nodes, go build it.

The only change I had to make with the image-builder template was to re-add a cloud-init disk.

#homelab #terraform #kubernetes #infrastructureascode #automation

🚀 𝗤𝘂𝗶𝗰𝗸 𝗴𝘂𝗶𝗱𝗲 𝗮𝘃𝗮𝗶𝗹𝗮𝗯𝗹𝗲

Deploy 𝗥𝗘𝗟𝗜𝗔𝗡𝗢𝗜𝗗 𝗟𝗼𝗮𝗱 𝗕𝗮𝗹𝗮𝗻𝗰𝗲𝗿 𝗘𝗻𝘁𝗲𝗿𝗽𝗿𝗶𝘀𝗲 𝘃𝟴 on 𝗔𝗪𝗦 with 𝗧𝗲𝗿𝗿𝗮𝗳𝗼𝗿𝗺 easily using the official module.

✔️ Ready-to-use infrastructure (VPC, subnet, security groups)

✔️ EC2 instance with RELIANOID AMI

✔️ SSH and Web GUI access

✔️ Clean teardown with terraform destroy

👉 https://www.relianoid.com/resources/knowledge-base/enterprise-edition-v8-administration-guide/deploy-relianoid-load-balancer-enterprise-edition-v8-with-terraform-on-aws/

#RELIANOID #Terraform #AWS #DevOps #FOSS #InfrastructureAsCode

“Migrations fail when visibility is stale, drift grows, and cutovers go manual.”

Migrating Puppet environments doesn’t have to be painful.

Tony Green shares hard‑won lessons from real-world migrations and how to stay in control when things get messy.

If you’re planning a Puppet migration (or already in the middle of one), this is well worth a read:

https://www.puppet.com/blog/puppet-mirgration-workflows

#Puppet #DevOps #InfrastructureAsCode #Automation

“Migrations fail when visibility is stale, drift grows, and cutovers go manual.”

Migrating Puppet environments doesn’t have to be painful.

Tony Green shares hard‑won lessons from real-world migrations and how to stay in control when things get messy.

If you’re planning a Puppet migration (or already in the middle of one), this is well worth a read:

https://www.puppet.com/blog/puppet-mirgration-workflows

#Puppet #DevOps #InfrastructureAsCode #Automation

Setting up a self-hosted Mattermost Team Edition server does not have to be a complex infrastructure puzzle. ☁️

You can deploy to Upsun with PostgreSQL 16 and OpenSearch 2, configured automatically from a single infrastructure-as-code file. ⚡

Read our guide to see how this simple configuration works and get your deployment started today.

👉 https://developer.upsun.com/posts/tutorials/deploy-mattermost-on-upsun

#Mattermost #DevOps #CloudNative #InfrastructureAsCode

Setting up a self-hosted Mattermost Team Edition server does not have to be a complex infrastructure puzzle. ☁️

You can deploy to Upsun with PostgreSQL 16 and OpenSearch 2, configured automatically from a single infrastructure-as-code file. ⚡

Read our guide to see how this simple configuration works and get your deployment started today.

👉 https://developer.upsun.com/posts/tutorials/deploy-mattermost-on-upsun

#Mattermost #DevOps #CloudNative #InfrastructureAsCode

I just added #Fedora 44 to our Integration Test Target (ITT) lineup:
👉 https://github.com/orgs/foundata/repositories?q=oci-*-itt

🔍 Looking for #Linux #Containers for your CI/CD pipeline? We’ve built a collection of OCI images:

✅ fully functional systemd (not just a shim!)
✅ unprivileged execution support, perfect for tools like #Podman.
✅ ideal for #Ansible #Molecule testing, see them in action with a collection: https://github.com/foundata/ansible-collection-sshd/tree/main/extensions/molecule

#Automation #DevOps #OpenSource #InfrastructureAsCode #foundata

@fedora
@ansible

I just added #Fedora 44 to our Integration Test Target (ITT) lineup:
👉 https://github.com/orgs/foundata/repositories?q=oci-*-itt

🔍 Looking for #Linux #Containers for your CI/CD pipeline? We’ve built a collection of OCI images:

✅ fully functional systemd (not just a shim!)
✅ unprivileged execution support, perfect for tools like #Podman.
✅ ideal for #Ansible #Molecule testing, see them in action with a collection: https://github.com/foundata/ansible-collection-sshd/tree/main/extensions/molecule

#Automation #DevOps #OpenSource #InfrastructureAsCode #foundata

@fedora
@ansible

Engineered a fault-tolerant multi-container web stack using Docker Compose IaC. Segmented Flask, PostgreSQL, Redis, and Nginx over a custom bridge network with automated health checks. Achieved instant horizontal scaling and full data persistence using volume orchestration. Reproducible, declarative infrastructure, no snowflake servers.

Github link:-https://github.com/saadcnx/multi-container-web-application

#Docker #DevOps #InfrastructureAsCode #OpenSource

A lot of teams are being told to “use AI in ops” right now. The harder part is figuring out *where it actually helps* day to day without adding risk, noise, or another thing to babysit.

If you’re curious (or skeptical 👀) about AI in ops, join Robin Tatam and Jason St-Cyr as they share their thoughts on where AI can realistically fit into infrastructure operations today. No magic, just using good tools to do better.

👉 https://www.puppet.com/resources/events/webinar/puppet-ai

#Puppet #InfrastructureAsCode #AIOps

A lot of teams are being told to “use AI in ops” right now. The harder part is figuring out *where it actually helps* day to day without adding risk, noise, or another thing to babysit.

If you’re curious (or skeptical 👀) about AI in ops, join Robin Tatam and Jason St-Cyr as they share their thoughts on where AI can realistically fit into infrastructure operations today. No magic, just using good tools to do better.

👉 https://www.puppet.com/resources/events/webinar/puppet-ai

#Puppet #InfrastructureAsCode #AIOps

📢 Puppet Continuous Delivery 5.15.0 available with improvements for stability, security, integrations, and usability.

Highlights include:
- New external_webhook_url support for proxy-based deployments
- Impact Analysis updates for Pipelines as Code
- Clearer GitLab commit status reporting
- Amazon Linux 2023 support for Docker-based installs
- Security and dependency updates addressing reported CVEs

Full release notes:
https://help.puppet.com/cdpe/current/Content/UserGuide/CDPE/ReleaseNotes/cd_release_notes.htm#Version5150

#Puppet #InfrastructureAsCode #ContinuousDelivery

📢 Puppet Continuous Delivery 5.15.0 available with improvements for stability, security, integrations, and usability.

Highlights include:
- New external_webhook_url support for proxy-based deployments
- Impact Analysis updates for Pipelines as Code
- Clearer GitLab commit status reporting
- Amazon Linux 2023 support for Docker-based installs
- Security and dependency updates addressing reported CVEs

Full release notes:
https://help.puppet.com/cdpe/current/Content/UserGuide/CDPE/ReleaseNotes/cd_release_notes.htm#Version5150

#Puppet #InfrastructureAsCode #ContinuousDelivery

Ever used Terraform Workspaces to separate environments? Did it feel quite cumbersome..?
This is how I use Terragrunt for all my projects using Terraform (or ToFu). What do you think? Comments very welcome!

https://github.com/katzefudder/terragrunt_demo

#terraform #devops #iac #infrastructureasCode

OpenTofu vs Terraform in 2026: the fork finally diverged

https://jorijn.com/en/blog/opentofu-vs-terraform-2026-the-fork-finally-diverged/

#Terraform #OpenTofu #InfrastructureAsCode #jorijncom

OpenTofu vs Terraform in 2026: the fork finally diverged

https://jorijn.com/en/blog/opentofu-vs-terraform-2026-the-fork-finally-diverged/

#Terraform #OpenTofu #InfrastructureAsCode #jorijncom

Puppet Security Compliance Management 3.7.0 is out!

This release focuses on keeping compliance stable as environments scale:
- New CIS benchmarks for modern Linux, macOS, and Windows 11
- More predictable scan performance with tunable JVM memory
- Stronger session and GraphQL API controls
- Security fixes and dependency updates (CVE items in the release notes!)

👇Check out the Release notes:
https://help.puppet.com/scm/current/Content/UserGuide/SCM/Release_notes/release_notes.htm#SecurityComplianceManagement370

#Puppet #Compliance #InfrastructureAsCode

Puppet Security Compliance Management 3.7.0 is out!

This release focuses on keeping compliance stable as environments scale:
- New CIS benchmarks for modern Linux, macOS, and Windows 11
- More predictable scan performance with tunable JVM memory
- Stronger session and GraphQL API controls
- Security fixes and dependency updates (CVE items in the release notes!)

👇Check out the Release notes:
https://help.puppet.com/scm/current/Content/UserGuide/SCM/Release_notes/release_notes.htm#SecurityComplianceManagement370

#Puppet #Compliance #InfrastructureAsCode

Build infrastructure that can burn down and bounce back. A guide to Minimal Viable Kubernetes. https://hackernoon.com/why-rebuilding-infrastructure-beats-upgrading-it #infrastructureascode

Follow-up to https://getnix.io/guides/nixos-auto-upgrades/ — here's how I handle upstream tracking for packages like Netbird:

1. Internal mirror syncs release tags from upstream source repository
2. CI detects new tags, updates the Nix flake (version + related hashes), builds & commits
3. Consumer repos pick up the change, open PRs with nvd diffs
4. Human reviews & merges
5. Hosts auto-deploy

Full pipeline runs unattended — you only step in to review the PR.

#nixos #nix #infrastructureascode #gitops

Platform Engineering vs. DevOps: What's behind Internal Developer Platforms?

Alexander Hoeft and Artem Lajko explain why companies should create a solid automation basis before building an Internal Developer Platform.

https://www.heise.de/en/background/Platform-Engineering-vs-DevOps-What-s-behind-Internal-Developer-Platforms-11256602.html?wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege&utm_source=mastodon

#Automatisierung #CloudNativeComputing #Developer #DevOps #InfrastructureasCode #IT #OpenSource #Softwareentwicklung #news

Platform Engineering vs. DevOps: Was steckt hinter Internal Developer Platforms?

Warum Firmen vor dem Aufbau einer Internal Developer Platform eine solide Automatisierungsbasis schaffen sollten, erklären Alexander Hoeft und Artem Lajko.

https://www.heise.de/hintergrund/Platform-Engineering-vs-DevOps-Was-steckt-hinter-Internal-Developer-Platforms-11255407.html?wt_mc=sm.red.ho.mastodon.mastodon.md_beitraege.md_beitraege&utm_source=mastodon

#Automatisierung #CloudNativeComputing #Developer #DevOps #InfrastructureasCode #IT #OpenSource #Softwareentwicklung #news