Ghostable v3 Beta: Serverless Git-Backed Secrets | Ghostable Article [ Blog ](https://ghostable.dev/blog) [ Articles ](https://ghostable.dev/blog/articles) [ Product Updates ](https://ghostable.dev/blog/category/product-updates) Saturday, June 20, 2026 Ghostable v3 beta: Serverless, Git-Backed Secrets =================================================== Ghostable's v3 beta CLI explores a serverless, Git-backed model for managing encrypted environment variables without ever touching a Ghostable server. ![Ghostable v3 beta: Serverless, Git-Backed Secrets](https://fls-9fca3102-944c-48ac-a3cc-22f1b47a39c7.laravel.cloud/blog/019ee582-07c4-70aa-ab92-4fc09dc51db7/ghostable-v3-teaser.jpg) Most teams already have a place where important project changes are reviewed, discussed, approved, reverted, and remembered. **It is Git.** That is what makes this Ghostable beta interesting to us. Instead of asking every team to add another hosted system as the source of truth for environment variables, this beta asks a simpler question: what if the encrypted source of truth could live alongside the project itself? The beta is available now in the [ghostable-dev/beta repository](https://github.com/ghostable-dev/beta). It is open source, free to use, and intentionally different from the current Ghostable product. We are sharing it early because it may shape a larger direction for Ghostable v3, and we want feedback before we treat that direction as settled. The Big Change -------------- The new beta is a Go-based CLI. It ships as a binary, which makes it easier to install and run in more places without depending on a Node runtime, package scripts, or a hosted Ghostable API. The larger change is the storage model. This client does not call Ghostable servers. Project metadata, device records, policy files, signed activity, environment keys, access grants, layouts, validation schema, and encrypted value files live under **.ghostable/**. Those files are intended to be committed to Git. Private device identity stays outside the repository in the platform's local secret store when possible, such as Keychain on macOS or Credential Manager on Windows. That means Ghostable is not sitting between your team and your secrets. There is no Ghostable-hosted database receiving encrypted environment state. There is no Ghostable server involved in the normal workflow. The encrypted project state moves through the Git system your team already uses. For teams that already trust GitHub, GitLab, Bitbucket, or another Git-backed workflow to review production-impacting changes, that is a meaningful shift. Why This Model Exists --------------------- Secrets workflows usually fail in boring ways. Someone has the latest **.env** file. Someone else has an older one. CI has a slightly different set of values. A deploy fails because a required key is missing. A teammate changes a token and forgets to explain why. A new developer gets blocked because the values they need are spread across chat messages, old onboarding notes, and one person's laptop. We have written before about why teams eventually [outgrow shared .env files](https://ghostable.dev/blog/share-env-files-safely). The problem is not only that plaintext files can leak. The problem is that plaintext files are a weak system of record. They do not review well. They do not explain themselves. They do not give teams a clean way to grant limited access, validate required values, or understand what changed. The beta keeps the useful parts of the Ghostable workflow while changing where the encrypted state lives. You can push and pull environment values, diff local files against stored values, validate variables against schema rules, copy values between environments, view signed history, deploy selected environments into local **.env** files, and scan the project for hard-coded secrets. The difference is that Git becomes the transport and review layer. One File Per Variable --------------------- One of the important details is that values are not stored as one encrypted blob per environment. Each variable is stored as its own encrypted value file. Git still cannot read the secret value, but it can show that a particular variable record changed. That is useful in a way a single encrypted environment archive is not. When a pull request changes **ghostable/environments/production/values/STRIPE\_SECRET\_KEY.json**, reviewers can see which variable record moved even though the plaintext value remains hidden. When a developer records a reason for a change, that context can travel with the signed activity. When a team needs to restore or audit a change locally, the history is closer to the actual unit of work. This is the kind of practical detail that matters. Developers do not only need encryption. They need to know what changed before they start guessing. Access Without A Ghostable Server --------------------------------- The beta also moves access control into the Git-backed project model. Devices have public records. Policies define who can own, read, write, or grant access. Environment keys are shared through per-device grants. Automation can use scoped credentials instead of a full human device identity. The role model is intentionally small: - Owners manage project-wide access and policy. - Readers can decrypt values for assigned environments. - Writers can update values for assigned environments. - Grantors can share access for assigned environments. That makes it possible to give a person read-only access to one environment, grant a deploy credential only the access it needs, or let a device request access without giving every machine the same authority. This is still a beta, so we care a lot about whether the model feels right in real projects. Access rules that are theoretically clean but awkward in daily work are not good enough. The goal is to make the secure path feel like the obvious path. The Security Boundary --------------------- Ghostable's current hosted product is already built around a zero-knowledge boundary. Plaintext values stay on trusted clients, and Ghostable is designed so it cannot read secret values. The beta keeps that core idea, but removes the Ghostable server from the storage path entirely. In this model, your Git provider stores encrypted blobs and signed metadata. Your local device or scoped automation credential performs the work it is allowed to perform. Private keys stay local or in the credential token you explicitly create for automation. That does not make every security concern disappear. Teams still need to protect developer machines, review repository access, rotate credentials when needed, and treat CI tokens carefully. Git-backed storage also means your Git review process matters more. If a team merges every **.ghostable/** change without review, the workflow will reflect that. But the trust boundary is different. Secret values are not passing through a Ghostable server, and Ghostable is not becoming a hosted system of record for your encrypted environment state. For teams evaluating vendor risk, that is worth testing. If you want the broader framing, Ghostable's existing [security model](https://ghostable.dev/security) explains why the line between access and plaintext exposure matters. What You Give Up ---------------- The current Ghostable product can provide a hosted audit surface that is independent from your Git repository. That has value, especially when teams want an immutable third-party record outside the place where code changes are made. This beta takes a different position. It makes the Git repository the place where encrypted state, signed activity, device records, and policy changes move. That can be simpler and more adoptable for many teams, but it also means Git history, branch protection, review discipline, and repository permissions become part of the operating model. The beta also does not work with the current Ghostable desktop client. A new desktop client for macOS, Windows, and Linux is planned, and feedback on this CLI will influence what that experience needs to become. For now, this is a CLI-first beta. Those tradeoffs are the point of sharing it early. We do not want to assume that the serverless model is better for every team. We want to understand where it feels cleaner, where it feels too manual, and where hosted Ghostable still gives teams something they would not want to lose. Why It Could Be Easier To Adopt ------------------------------- The best infrastructure tools fit into systems teams already trust. Most teams already have Git. They already review pull requests. They already have branch protection. They already know how to revert a bad change. They already know how to inspect history, approve access to repositories, and wire Git into deploy workflows. That does not mean Git is a secrets manager. It means Git can be a strong coordination layer when the information stored in Git is clean, encrypted, signed, and safe to commit. That is the bet behind this beta. Keep plaintext local. Commit encrypted variable records. Use signed device and policy files to describe who can do what. Let teams review environment changes through the same workflow they use for code. For a lot of projects, that may be a more natural model than adding another hosted control plane. Try It And Tell Us What You Think --------------------------------- Try the beta in a real project or a throwaway copy of one. Push a **.env** file into the default environment. Pull it back out. Change a value and look at the Git diff. Create another environment. Test validation. Create a scoped credential for automation. See whether the access model makes sense to you without a hosted Ghostable server. We especially want to know: - Whether Git-backed encrypted state feels safer, clearer, or simpler than a hosted source of truth. - Whether per-variable encrypted files make review easier. - Whether device roles and scoped automation credentials match real team workflows. - Whether the loss of a hosted immutable audit surface is acceptable, or a dealbreaker. The repository is here: [github.com/ghostable-dev/beta](https://github.com/ghostable-dev/beta). If this direction works, Ghostable becomes simpler in an important way. Your team keeps the storage and review system it already uses. Ghostable provides the local encryption, access model, validation, deployment support, and workflow around it. [ Back to blog ](https://ghostable.dev/blog) [All articles](https://ghostable.dev/blog/articles) Want product news and updates? -------------------------------- Sign up for our newsletter. Email Address Subscribe → Subscribing... We care about your data. Read our [privacy policy](https://ghostable.dev/privacy).