Tawbar: a collaboration tool for .env files we built for ourselves
Tawbar is our own pet project: a web tool for teams to manage and sync .env configuration files across developers, machines, and environments. We built it in 2022 because we couldn’t find anything that solved the problem well.
Challenge
Every frontend developer knows the ritual. You clone a repo, run npm install, start the dev server, and it crashes. Missing environment variables. You ping a teammate on Slack: “Can you send me the .env for this project?” They dig through their machine, copy the file, paste it into a DM. Half the values are stale. Two are wrong for your local setup. You spend the next hour debugging.
This was our daily reality. We work across multiple client projects, each with its own set of API keys, service URLs, and feature flags spread across development, staging, and production environments. The .env file, by design, lives outside version control. That’s the right call for security, but it creates a real coordination problem.
We looked for tools that solved this. Secret managers like HashiCorp Vault and AWS Secrets Manager exist, but they’re built for infrastructure teams managing production deployments. They’re overkill for a frontend team that just needs to keep .env files organized and shared. Other solutions either required migrating to a new deployment platform or changing how you write code. We wanted something simpler:
- A single place where the team can see all variables for all environments
- A way to pull secrets to a local
.envfile with one command - Real-time sync so changes propagate without Slack messages
- API access for CI/CD pipelines
Nothing fit. So we built it.
Approach
A grid that maps to how developers think
The core design decision was the interface. We chose a grid layout where each row is a variable name and each column is an environment (develop, production, preview, or whatever the project uses). This matches the mental model developers already have: “What’s the value of API_URL in production vs. development?”
You can drag columns to reorder environments, import an existing .env file to populate the grid in bulk, and export any environment back to a .env file. Adding a new variable or environment takes a single click. The table updates in real time through Firestore listeners, so when one developer changes a value, everyone on the team sees it immediately.
We kept the UI deliberately minimal. No dashboards, no analytics, no onboarding wizards. Open the project, see your variables, edit what you need.
A CLI that fits into existing workflows
The web interface handles collaboration, but developers live in the terminal. We built tawbar-cli as an npm package with a small, familiar command set:
npm install -g tawbar-cli
tawbar login
tawbar fetch my-project developmenttawbar fetch pulls the secrets for a given project and environment and writes them to a local .env file. That’s the main command. A new developer joining the team runs two commands and has a working environment.
The CLI authenticates through a device authorization flow (similar to GitHub CLI) and supports both user-level tokens for interactive use and project-level tokens for automated pipelines. Project tokens are scoped to a single project’s read-only data, so they’re safe to store in CI configuration.
Webhooks and API for automation
Some teams wanted tawbar to fit into their deployment pipelines. When a secret changes in production, the staging environment should know about it. We added webhooks that fire HTTP POST requests whenever values change in a watched environment. A scheduled Cloud Function processes the webhook queue every minute, keeping the system decoupled from user actions.
For direct integration, we built a REST API. A GET request to /projects/v1/{PROJECT_ID}/{STATE} with a valid token returns the secrets in standard .env format, ready to pipe into a file or parse in a script.
Team management and audit trail
Tawbar organizes work around organizations. You invite teammates by email, and everyone in the organization can access its projects. Every change records who made it and when, so the audit log answers the question “who changed STRIPE_KEY in production last Tuesday?” without guessing.
We added Stripe billing early, with a simple per-member pricing model. No tiers, no feature gates. One plan, full access.
Results
Tawbar hasn’t become a breakout product. We’re honest about that. The .env management space is small and niche, and most teams solve the problem with “good enough” workarounds: shared password managers, pinned Slack messages, or internal wikis.
But it works, and it’s used. Hundreds of users manage their secrets through Tawbar, and we still use it across our own projects. Onboarding a new developer to a client project takes minutes instead of the back-and-forth that used to eat half a morning.
The tool is in maintenance mode now. It runs, it’s stable, and it does what it was built to do. We’re not actively developing new features, but we haven’t needed to: the core problem hasn’t changed, and the solution still fits.
Building Tawbar was also an exercise in shipping a real product with a small team. We made decisions about billing, authentication, API design, and developer experience that we later applied to client work. The lessons from maintaining a SaaS product, even a small one, made us better at building them for others.
