GOgoncalo-r·Jul 21, 2023
This is what Multy (https://github.com/multycloud/multy) aims to do
In Rethinking Infrastructure as Code from Scratchmultycloud
multy
Go2022–2023
multycloud / multy
multy
Multy - Easily deploy multi cloud infrastructure. Write cloud-agnostic config deployed across multiple clouds
5Distinct people
8Mentions
0Explicit recommenders
661GitHub stars
What to know before exploring
What it is
Multy - Easily deploy multi cloud infrastructure. Write cloud-agnostic config deployed across multiple clouds
GitHub
Where it is used
No documented product use has been verified yet.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by month8 dated mentions
Observed mentions: 2022-05-09 12:53:45 UTC to 2023-07-21 17:14:01 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| May 2022 | 2022-05-01 00:00:00 UTC | 2022-06-01 00:00:00 UTC | 3 | 2 | 1 |
| Jun 2022 | 2022-06-01 00:00:00 UTC | 2022-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2022 | 2022-07-01 00:00:00 UTC | 2022-08-01 00:00:00 UTC | 1 | 1 | 0 |
| Aug 2022 | 2022-08-01 00:00:00 UTC | 2022-09-01 00:00:00 UTC | 2 | 2 | 0 |
| Sep 2022 | 2022-09-01 00:00:00 UTC | 2022-10-01 00:00:00 UTC | 0 | 0 | 0 |
| Oct 2022 | 2022-10-01 00:00:00 UTC | 2022-11-01 00:00:00 UTC | 0 | 0 | 0 |
| Nov 2022 | 2022-11-01 00:00:00 UTC | 2022-12-01 00:00:00 UTC | 0 | 0 | 0 |
| Dec 2022 | 2022-12-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 0 | 0 | 0 |
| Jan 2023 | 2023-01-01 00:00:00 UTC | 2023-02-01 00:00:00 UTC | 1 | 0 | 1 |
| Feb 2023 | 2023-02-01 00:00:00 UTC | 2023-03-01 00:00:00 UTC | 0 | 0 | 0 |
| Mar 2023 | 2023-03-01 00:00:00 UTC | 2023-04-01 00:00:00 UTC | 0 | 0 | 0 |
| Apr 2023 | 2023-04-01 00:00:00 UTC | 2023-05-01 00:00:00 UTC | 0 | 0 | 0 |
| May 2023 | 2023-05-01 00:00:00 UTC | 2023-06-01 00:00:00 UTC | 0 | 0 | 0 |
| Jun 2023 | 2023-06-01 00:00:00 UTC | 2023-07-01 00:00:00 UTC | 0 | 0 | 0 |
| Jul 2023 | 2023-07-01 00:00:00 UTC | 2023-08-01 00:00:00 UTC | 1 | 0 | 1 |
What Hacker News says
8 sourcesThere is already a couple of options
https://github.com/multycloud/multy
But a multicloud wrapper creates a lot of abstractions.
In Writing an IaC Rosetta StoneShow HN: Build for any cloud with the same code
We have been working on Multy, an open-source[1] tool that enables developers to deploy and switch to any cloud - AWS, Azure and GCP for now.
We realized that, even when using Terraform, writing infrastructure code is very different for each cloud provider. This means changing clouds or deploying the same infrastructure in multiple clouds requires rewriting the same thing multiple times. And even though most core resources have the same functionality, developers need to learn a new provider and all its nuances when choosing a new cloud. This is why we built Multy.
Multy is currently available as a Terraform provider. You can write cloud-agnostic code and then just choose which cloud you want to deploy to. Multy will then call the cloud provider APIs on your behalf. For example, the following Terraform code deploys a virtual network in AWS
Read the rest
and can be easily changed to deploy to Azure or GCP:
```
resource "multy_virtual_network" "vn" {
cloud = "aws" // or azure, or gcp
name = "multy_vn"
cidr_block = "10.0.0.0/16"
location = "eu_west_1"
}
```
Our goal is to expose any configuration that is common across all clouds, but there’s always specific features that are not available in all of them. For example, if you want a very specific AWS CPU for your Virtual Machine or use a region that is only available in GCP. To enable this, we implemented overrides [2] - a way to configure the underlying infrastructure for cloud-specific purposes. You can also mix other Terraform code that uses the cloud-specific providers with Multy. While this makes you somewhat locked in, having your 80% or 90% of your infrastructure cloud-agnostic is still very powerful.
You can see more complex examples in our documentation - https://docs.multy.dev/examples/.
We’re still in early days and looking for feedback from other developers on our approach. Let us know what you think!
[1] https://github.com/multycloud/multy
[2] https://docs.multy.dev/overrides
Show HN: Multy – open-source tool to deploy to any cloud and switch at any time
We have been working on Multy, an open-source[1] tool that enables developers to deploy and switch to any cloud - AWS, Azure and GCP for now.
We realized that, even when using Terraform, writing infrastructure code is very different for each cloud provider. This means changing clouds or deploying the same infrastructure in multiple clouds requires rewriting the same thing multiple times. And even though most core resources have the same functionality, developers need to learn a new provider and all its nuances when choosing a new cloud. This is why we built Multy.
Multy is currently available as a Terraform provider. You can write cloud-agnostic code and then just choose which cloud you want to deploy to. Multy will then call the cloud provider APIs on your behalf. For example, the following Terraform code deploys a virtual network in AWS
Read the rest
and can be easily changed to deploy to Azure or GCP:
resource "multy_virtual_network" "vn" {
cloud = "aws" // or azure, or gcp
name = "multy_vn"
cidr_block = "10.0.0.0/16"
location = "eu_west_1"
}
Our goal is to expose any configuration that is common across all clouds, but there’s always specific features that are not available in all of them. For example, if you want a very specific AWS CPU for your Virtual Machine or use a region that is only available in GCP. To enable this, we implemented overrides [2] - a way to configure the underlying infrastructure for cloud-specific purposes. You can also mix other Terraform code that uses the cloud-specific providers with Multy. While this makes you somewhat locked in, having your 80% or 90% of your infrastructure cloud-agnostic is still very powerful.
You can see more complex examples in our documentation - https://docs.multy.dev/examples/.
We’re still in early days and looking for feedback from other developers on our approach. Let us know what you think!
[1] https://github.com/multycloud/multy
[2] https://docs.multy.dev/overrides
Show HN: Multy – open-source tool to deploy to any cloud and switch at any time
We have been working on Multy, an open-source[1] tool that enables developers to deploy and switch to any cloud - AWS, Azure and GCP for now.
We realized that, even when using Terraform, writing infrastructure code is very different for each cloud provider. This means changing clouds or deploying the same infrastructure in multiple clouds requires rewriting the same thing multiple times. And even though most core resources have the same functionality, developers need to learn a new provider and all its nuances when choosing a new cloud. This is why we built Multy.
Multy is currently available as a Terraform provider. You can write cloud-agnostic code and then just choose which cloud you want to deploy to. Multy will then call the cloud provider APIs on your behalf. For example, the following Terraform code deploys a virtual network in AWS
Read the rest
and can be easily changed to deploy to Azure or GCP:
resource "multy_virtual_network" "vn" {
cloud = "aws" // or azure, or gcp
name = "multy_vn"
cidr_block = "10.0.0.0/16"
location = "eu_west_1"
}
Our goal is to expose any configuration that is common across all clouds, but there’s always specific features that are not available in all of them. For example, if you want a very specific AWS CPU for your Virtual Machine or use a region that is only available in GCP. To enable this, we implemented overrides [2] - a way to configure the underlying infrastructure for cloud-specific purposes. You can also mix other Terraform code that uses the cloud-specific providers with Multy. While this makes you somewhat locked in, having your 80% or 90% of your infrastructure cloud-agnostic is still very powerful.
You can see more complex examples in our documentation - https://docs.multy.dev/examples/.
We’re still in early days and looking for feedback from other developers on our approach. Let us know what you think!
[1] https://github.com/multycloud/multy
[2] https://docs.multy.dev/overrides
Multy – Easily deploy multi cloud infrastructure across multiple clouds
1 points · Open discussionShow HN: Open-source tool to deploy infrastructure in any cloud
We have been working on multy.dev, an open-source cloud agnostic API that makes it easy to deploy the same infrastructure to any cloud provider using native managed services.
The motivation was the realisation that, even when using Terraform, migrating infrastructure code requires an end-to-end re-write. Even though most core resources are the same in any major cloud, developers need to learn a new provider to deploy the same infrastructure when moving providers.
We are still in early days of development and currently support the core services from AWS and Azure:
- Networking (virtual_network, subnet, route_table, security_group, network_interface, public_ip)
- Compute (virtual_machine, managed kubernetes)
- Database (managed MySQL databases)
- Vault (managed secrets)
- Storage (managed storage)
- Abstraction of cloud differences (Azure V
Read the rest
M public vs AWS EC2 private by default)
- Deployment through Terraform
We’re looking for feedback from other developers about our approach. Let us know your thoughts!
GitHub: https://github.com/multycloud/multy
Me and a few friends have been working on multy.dev, an open-source[1] cloud agnostic API that makes it easy to deploy the same infrastructure to any cloud provider using native managed services.
The motivation was the realisation that, even when using Terraform, migrating infrastructure code requires an end-to-end re-write. Even though most core resources are the same in any major cloud, developers need to learn a new provider to deploy the same infrastructure when moving providers.
We are still in early days of development and currently support core services from AWS and Azure:
- Networking (virtual_network, subnet, route_table, security_group, network_interface, public_ip)
- Compute (virtual_machine, managed kubernetes)
- Database (managed MySQL databases)
- Vault (managed secrets)
- Storage (managed storage)
-
Read the rest
Abstraction cloud differences (Azure VM public vs AWS EC2 private by default)
- Deployment through Terraform
We’re looking for feedback from developers about our approach and messaging. Let us know your thoughts!
[1] https://github.com/multycloud/multy