Puls is taking its next major step toward modularity and zero dependency-bloat. We have split the monolithic puls-dev codebase into separate, scoped sub-packages within an npm workspace monorepo layout: @puls-dev/core and individual provider packages like @puls-dev/aws, @puls-dev/gcp, @puls-dev/do, and @puls-dev/firebase.
Today, we are excited to release Puls v0.4.9! This release marks a significant architectural milestone for Puls as we decouple the core infrastructure engine from individual cloud provider implementations. We have also added complete support for local E2E testing against Firebase Local Emulators.
If you've managed cloud resources over the last decade, you've likely had a run-in with a state file.
Whether it's Terraform's .tfstate or Pulumi's stack state, traditional Infrastructure-as-Code (IaC) tools rely on a centralized ledger. This file is their source of truth-a mapping of declared resource names to physical cloud IDs, tracking metadata and dependencies.
While state files solved a major problem in the early days of cloud automation, they introduced a host of operational challenges that teams spend hundreds of engineering hours managing.
Puls is built around a different philosophy: what if we didn't need state files at all?
Hardcoding credentials in your version control system is one of the most common ways security leaks happen. Whether it's an API token, a database root password, or a service account key, committing credentials to Git is a recipe for disaster.
Yet, managing these secrets on team projects is often painful. Developers end up sharing .env files via Slack, updating private vaults manually, or writing complex bootstrap scripts.
Puls solves this with Secrets at Deploy Time: a lazy-resolved, type-safe secret engine that fetches passwords directly from secure cloud vaults when deploying, with native injection into your VM environments and provisioning scripts.