File encryption
Your .env files are encrypted at rest, and Postgres Row Level Security enforces who can even read them at the database layer, not just the UI.
Secure .env file sharing and secrets storage for your team: AES-256 encryption, role-based access, and expiring links instead of pasting API keys into chat.
No more pasting API keys and database passwords into Slack. Upload once, and share.env handles encryption, links, and access for you.
Drag in your environment file or paste its contents. It's stored in your workspace, not in a chat thread.
Every secret is encrypted in Supabase Storage and protected by row-level security, so only authorized requests ever reach it.
Create a link with a high-entropy token, an expiry date, and revoke it instantly whenever access should end.
Invite teammates by email or workspace role owner, editor, or viewer and permissions are enforced on every request.
Every .env file lives in a team workspace, not on one person's laptop with access control and version history from day one.
Your .env files are encrypted at rest, and Postgres Row Level Security enforces who can even read them at the database layer, not just the UI.
Share a file without inviting someone to the team every link carries an expiry date and can be revoked instantly, at any time.
Owner, editor, and viewer roles decide who can edit secrets and who can only view them enforced by database policies, not just hidden in the UI.
Every change to a .env file is recorded, so you always know who changed which secret and when and can roll back to a previous version.
Pull the current environment variables straight into your deployment pipeline, without copying secrets between environments by hand.
Technical people who decide where their team's secrets live, on what convinced them to switch to share.env.
API keys used to float around in Slack threads. Now every secret has an owner, a version history, and a link I can revoke in one click security audits stopped being a nightmare.
The real difference is RLS at the database layer, not just the UI. Even if someone bypassed the frontend, they can't pull another team's environment variables that's the bar I expect from a secrets tool.
Rollout took an afternoon: CLI wired into CI/CD, owner/editor/viewer roles for the team, and no more copying .env files between environments by hand. Simple without giving up control.
Send us a message we usually reply to security and onboarding questions the same business day.
Every .env file's content is encrypted with AES-256-GCM before it's ever written to storage only the encrypted envelope (ciphertext, IV, and authentication tag) lands in Supabase Storage, never the plaintext secrets. GCM is authenticated encryption: any attempt to tamper with the encrypted data causes decryption to fail loudly instead of silently returning corrupted content. On top of that, Supabase Storage applies its own default encryption at rest, and Postgres Row Level Security ensures only queries authorized for your workspace can read the underlying records. As a result, even someone with direct access to the database or storage bucket can't read your secrets without the encryption key.
Files and their version history are kept for as long as the workspace stays active. Deleting a workspace or a specific file also removes its stored versions and share links we don't keep copies outside your account's active scope.
Yes. Every change to a .env file is logged with who made it and when, so the version history doubles as an audit trail for the whole workspace. Token-based share links always carry a mandatory expiration date, and any owner or editor can revoke a link at any time from the dashboard revocation takes effect immediately and blocks further access through that link, even if someone already opened it. The same applies to role-based access: removing someone from a workspace or downgrading them to viewer instantly limits what they can read or edit, because permissions are enforced by RLS policies rather than just hidden UI buttons.
Right now share.env only runs as a hosted service self-hosting isn't supported. The whole stack (database, auth, storage) runs on Supabase, with the application layer hosted on Vercel, which lets us maintain one consistently high security bar (RLS on every table and bucket, AES-256-GCM encryption of file contents, rate limiting on public endpoints) instead of pushing server patching and hardening onto you. We've also deliberately skipped client-side zero-knowledge end-to-end encryption in favor of this model it keeps team sharing simple (owner/editor/viewer roles, token-based links) while still layering on the protections above. If self-hosting is a hard requirement for you, reach out directly we treat that feedback as a signal for roadmap prioritization.
Deleting your account permanently removes files you solely owned, along with their version history and active share links. Files belonging to workspaces with other members remain accessible to the remaining members with the right role.
Create a workspace, upload your first .env file, and share it with your team in under two minutes.