Today, we’re excited to announce that we’re working with the Pulumi community to provide a place to interact and collaborate on Pulumi-based libraries, projects, and educational materials: the Pulumiverse.
Managing DNS records efficiently is crucial for anyone who owns multiple domains. Whether you’re handling infrastructure for a business, securing brand assets, or just keeping personal projects organized, having a structured approach to DNS management can save time and prevent headaches.
With Pulumi, you can automate DNS configuration, ensure consistency across providers, and make changes programmatically—reducing manual work and human error. In this post, we’ll walk through how to use Pulumi to manage DNS records dynamically and effectively.
What is user experience, or UX? There are plenty of answers depending on who you ask. At the core, UX is about asking questions and solving problems.
We are excited to announce v5.0.0 of the Pulumi AWS provider. The AWS provider is one of the most heavily used providers across the Pulumi ecosystem, and offers access to the full surface area of the upstream Terraform AWS Provider from within Pulumi projects in all supported Pulumi languages. The v5.0.0 release brings a substantial set of fixes and improvements to the provider, including a number of breaking changes as part of the major version release.
parentTeamId of the Team resource accepts a string instead of an int since v5.9.1 of the
Pulumi Github package.Ah, GitHub. The home of all developers. The place where we share code. The world’s most awkward social media site. The secret LinkedIn for techies. The tool we use for company org structure, work planning, code ownership, and permissions…
Wait.
That’s quite a lot.
GitHub is good at many things, but a full-on organization management tool it is not.
Have you ever needed your manager to manually enable admin permission on a repo for you? Or have you needed to page the CEO to add you to a team, because your manager was out that day? Have you ever wondered who is on what team? Or which team owns a repo? What if you change teams, or a team changes names? A reorg happens, and the “platform-integrations” team is no more, but we still need to call it that on GitHub because it is the team with all the repository accesses?
When I joined Pulumi in 2021, all of the above happened to me within my first few weeks.
We at Pulumi wanted to reduce this kind of management friction, and we decided to solve it the Pulumi way: with declarative infrastructure using the Pulumi GitHub provider.
Pulumi community member Sanjay Bhagia explores using Pulumi to manage secrets.
The team has been busy releasing new features and improvements in the last 3 weeks. Read on to learn about what’s new in this release!
This blog post discusses hierarchical config before Pulumi ESC was released. ESC makes hierarchical config easy.
A really common question that we receive on the Pulumi team is, “How can we set config at a project level, that can be used across all stacks?”.
When I say “really common” … I mean really, really common.
This issue was first open in 2018 and has received 52 votes from the community. Not only that, we’ve had plenty of similar issues created over the years too.
Last year, we introduced a new Pulumi feature that allows you to import existing infrastructure into your Pulumi program. Not only did it bring the resource into the Pulumi state file, but it could generate the source code for your Pulumi program too. Today, we’re excited to announce that we’ve listened to feedback and delivered a plethora of updates and fixes to streamline the import experience; to make it more useful, more convenient, and more powerful.
![Deploy MERN Stack on DigitalOcean with Pulumi [Guide]](/blog/fullstack-pulumi-mern-stack-digitalocean/meta.png)
As a developer, I get lots of ideas for web apps—little things, mostly: nifty ways to keep track of my kids’ allowances, habit trackers, shopping lists. Most of them, however, never see the light of day, and not just because I’m lazy; I also tend to get hung up trying to decide what to use for the technology stack.
