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)

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 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? 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, HIPAA, PCI — 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?

  • Copy–pasting secrets into chat or email
  • Uploading .env files (zipped or plain text) to shared storage (e.g., Google Drive, Dropbox)
  • Committing secrets into Git repositories
  • Pasting secrets into collaboration tools (e.g., Jira, Shortcut, Linear, Trello)
  • Sharing screenshots or raw snippets in tickets or docs

Encrypted or not, once secrets live in systems not built for them, they’re out of your control. A single account breach, integration misfire, or misconfigured share link is all it takes.

“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
  • Private Notion or Confluence 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, Infisical, or Vault 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

This is where Ghostable comes in — built specifically for Laravel teams and the way they actually work. Instead of treating secrets as generic key–values, it understands .env files, validation rules, and agency/client workflows out of the box:

Securely manage, effortlessly sync, automatically validate, audit changes, and confidently deploy your Laravel environment variables and secrets—all within one unified platform.

  • One-command push/pull for environments
    ghostable env:pull
    ghostable env:push
    
  • Invite agencies or clients with read-only or read-write roles
  • Validation rules enforce required variables like APP_KEY or DB_CONNECTION
  • Full audit history of every change for accountability and compliance
  • Specific deployment commands with Forge, Vapor, or Laravel Cloud are simple.

Real-World Workflow

  1. Navigate to Organization → Settings → Members.
  2. Invite your client to the organization as either a Developer or Developer (read-only).
  3. (Optional) On paid tiers, you can also go to Project → Settings → Access to set custom permission overrides for a specific project.
  4. Once added, the agency or client developer can run Ghostable CLI commands to securely push and pull environment variables.

Every action is tracked — from invitations to variable changes — giving you a complete audit trail for accountability and compliance.

Make the Secure Path the Easy and Default Path

Ghostable makes .env sharing safe, fast, and auditable.

👉 Start free — push your .env in 60 seconds

Want product news and updates?

Sign up for our newsletter.

Email Address

We care about your data. Read our privacy policy.