How to Share .env Files Safely with Agencies & Clients (Without Risking Secrets) \| Ghostable Article [ Blog ](https://ghostable.dev/blog) [ Articles ](https://ghostable.dev/blog/articles) [ Best Practices ](https://ghostable.dev/blog/category/best-practices) Tuesday, September 23, 2025 How to Share .env Files Safely with Agencies & Clients (Without Risking Secrets) ====================================================================================== Learn the safest ways to share .env files with freelancers, agencies, and clients. Avoid email/Slack leaks, prevent drift, and keep your Laravel environments secure with versioning, validation, and audit trails. ![How to Share .env Files Safely with Agencies & Clients (Without Risking Secrets)](https://fls-9fca3102-944c-48ac-a3cc-22f1b47a39c7.laravel.cloud/blog/019973e7-3d5f-719d-b04c-846b08e18b73/189E9B06-FD8F-438F-82EC-DB8844331745.png) Every Laravel team eventually has to hand off an `.env` file. Most do it the wrong way — emailing secrets or dropping them into Slack. That one shortcut can cause leaks, mismatched environments, or failed deploys. The good news: safer patterns exist. Let’s walk through what **not** to do, and the modern approach to `.env` handoffs. Why Sharing ENV Files is Risky ------------------------------ Sending secrets over email or [Slack](https://slack.com) might feel quick, but the moment you hit send, you’ve lost control. Those values live forever in plaintext, often sitting in inboxes, chat history, or backups you don’t own. Now, you might be thinking: realistically, what are the odds that [someone malicious actually gets hold of those keys](https://ghostable.dev/blog/laravel-app-key-vulnerability)? Fair question. In many cases, you’ll get away with it. But the truth is it only has to happen once. One wrong forward, one compromised account, and suddenly the “temporary shortcut” becomes a serious breach. Worse, it sets a precedent — if you do it once, your team is more likely to do it again. And there’s also the lack of visibility. Without a proper system, you can’t answer simple questions like “who changed this variable, and when?” If your team is under compliance requirements — [SOC 2](https://secureframe.com/hub/soc-2/what-is-soc-2), [HIPAA](https://www.hhs.gov/hipaa/index.html), [PCI](https://www.pcisecuritystandards.org) — moving secrets this way is more than sloppy, it’s a straight-up audit failure. The Wrong Ways (Common Pitfalls) -------------------------------- ### Never Do This Some practices are **instant red flags**. If your team is doing any of these, stop immediately: ![Slack screenshot of a conversation in the #engineering channel. Dinesh Chugtai asks for a new Stripe secret key because his expired. Richard Hendricks replies by pasting a redacted STRIPE_SECRET value. Gilfoyle sarcastically comments, ‘Congratulations. You’ve just turned Slack into our new secrets manager. Should I add it to the SOC 2 audit docs?](https://fls-9fca3102-944c-48ac-a3cc-22f1b47a39c7.laravel.cloud/blog/019973e7-3d5f-719d-b04c-846b08e18b73/slack_screenshot_sharing_secrets.jpg) - Copy–pasting secrets into chat or email - Uploading .env files (zipped or plain text) to shared storage (e.g., [Google Drive](https://workspace.google.com/security/), [Dropbox](https://www.dropbox.com/features/security)) - Committing plaintext secrets into Git repositories - Pasting secrets into collaboration tools (e.g., [Jira](https://www.atlassian.com/trust), [Shortcut](https://shortcut.com/security), Linear, [Trello](https://trello.com/trust)) - Sharing screenshots or raw snippets in tickets or docs A copied plaintext secret can remain usable long after a message or shared file is deleted. Encrypted project state is different: the values are encrypted before they enter Git, and access requires the appropriate device keys. Keep plaintext files and private keys out of the repository. ### “Better” But Still Wrong Some approaches might look safer than blasting an email, but they’re still just as flawed in practice: - Secure notes in [LastPass](https://www.lastpass.com/security) - Private [Notion](https://www.notion.so/help/security-and-privacy) or [Confluence](https://www.atlassian.com/trust) pages - Dropbox folders “just for the team” - Sending keys over SMS - Calling someone and reading the values aloud They may reduce casual exposure, but they don’t provide real secrets management. There’s no audit trail, no safe versioning, and no way to guarantee the values will be cleaned up later. At best, these are temporary band-aids that normalize bad habits. Safer Alternatives ------------------ ### Use a Secrets Manager Generic tools like [Doppler](https://www.doppler.com/), Infisical, or [Vault](https://www.vaultproject.io/) are an improvement — they centralize secrets and enforce some access controls. But they fall short in Laravel environments for a few reasons: **No .env semantics** - These tools treat secrets as arbitrary key–value pairs. They don’t understand Laravel conventions like .env.example, environment-specific overrides, or the way framework features (e.g., queue workers, Forge/Vapor deploys) expect environment files to exist in a certain shape. **No built-in validation** - They can store secrets, but they don’t enforce which variables are required for your app to boot properly. A missing APP\_KEY or DB\_CONNECTION won’t be flagged until production breaks. Laravel-specific validation rules (like you’d do in config or request validation) don’t exist here. **Workflow mismatch** - Many agencies and freelancers hand off .env files directly to clients or external partners. Generic managers aren’t designed for those ad hoc, project-based relationships. They assume a single, centralized org with permanent team members — not rotating contractors and clients who need read-only or time-limited access. ### Use Ghostable Ghostable V3 keeps encrypted environment values in your project's `.ghostable/` directory. Teams review and share that state through Git, while each device keeps its private identity outside the repository. An agency or client can receive access to the environments they need without someone sending them a plaintext `.env` file. Environment roles control what their device can read or change. The CLI and Desktop use the same project state. A practical handoff ------------------- The recipient clones the repository, creates a device identity, and requests access. An owner or grantor reviews the request and commits the signed grant. After receiving that commit, the recipient can decrypt the approved environment locally. The [V3 team onboarding guide](https://ghostable.dev/docs/3.x/getting-started/team-onboarding) covers the workflow. Repository access alone does not grant permission to decrypt values. When the engagement ends, revoke the device's access and commit the change. Rotate any underlying credentials the recipient should no longer be able to use. Make secure sharing part of the project --------------------------------------- Keep encrypted values, access changes, and configuration history with the code they belong to. Start with the [V3 setup guide](https://ghostable.dev/docs/3.x/getting-started/new-projects). [ 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).