<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: sozenka</title>
    <description>The latest articles on DEV Community by sozenka (@sozenka).</description>
    <link>https://dev.to/sozenka</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4187610%2F8d7c3b61-3fae-4b35-926a-2de770aec1f6.jpg</url>
      <title>DEV Community: sozenka</title>
      <link>https://dev.to/sozenka</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/sozenka"/>
    <language>en</language>
    <item>
      <title>Stop committing your .env file</title>
      <dc:creator>sozenka</dc:creator>
      <pubDate>Fri, 16 Oct 2026 00:16:04 +0000</pubDate>
      <link>https://dev.to/sozenka/stop-committing-your-env-file-5agk</link>
      <guid>https://dev.to/sozenka/stop-committing-your-env-file-5agk</guid>
      <description>&lt;p&gt;Secrets leak through git every day (especially for new coders and vibe coders): API keys, database URLs, cloud credentials. Most of them come from the same place: a .env file that was committed by accident, or a key pasted into a config “just for now.” &lt;/p&gt;

&lt;p&gt;And deleting the commit doesn’t fix it. Once a secret has been pushed, assume it’s compromised.&lt;/p&gt;

&lt;p&gt;Here are three habits that prevent it, from simplest to strictest.&lt;/p&gt;

&lt;h2&gt;
  
  
  1. Ignore it before it exists
&lt;/h2&gt;

&lt;p&gt;Add .env to .gitignore on day one, before the file is created. Keep a .env.example with fake values so new contributors know which variables to set.&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight plaintext"&gt;&lt;code&gt;.env
*.env.local
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;This stops most accidents, but it doesn’t solve sharing: people still end up sending the real .env over chat.&lt;/p&gt;

&lt;h2&gt;
  
  
  2. Encrypt the real file and commit the ciphertext
&lt;/h2&gt;

&lt;p&gt;Commit an encrypted version of the file instead. Teammates get the secrets from the repo; GitHub only ever sees encrypted bytes.&lt;/p&gt;

&lt;p&gt;Options:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;SOPS: the most flexible. Works with age, PGP, AWS/GCP/Azure KMS, and can encrypt individual values inside YAML/JSON.&lt;/li&gt;
&lt;li&gt;dotenvx: keypair-based encryption for .env files.&lt;/li&gt;
&lt;li&gt;sealenv: a small Rust CLI I wrote for teams that want zero setup:
&lt;/li&gt;
&lt;/ul&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;sealenv init      &lt;span class="c"&gt;# generates a key in ~/.sealenv/keys, updates .gitignore&lt;/span&gt;
sealenv encrypt   &lt;span class="c"&gt;# .env -&amp;gt; .env.enc (AES-256-GCM)&lt;/span&gt;
git add .env.enc
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;The key never touches the repo. Share it once with sealenv key export / key import.&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Never write plaintext to disk&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;The strictest option is to decrypt into memory and inject the variables straight into your process:&lt;br&gt;
&lt;/p&gt;

&lt;div class="highlight js-code-highlight"&gt;
&lt;pre class="highlight shell"&gt;&lt;code&gt;sealenv run &lt;span class="nt"&gt;--&lt;/span&gt; npm start
&lt;span class="c"&gt;# or: sops exec-env secrets.enc.env 'npm start'&lt;/span&gt;
&lt;span class="c"&gt;# or: op run -- npm start     (1Password CLI)&lt;/span&gt;
&lt;/code&gt;&lt;/pre&gt;

&lt;/div&gt;



&lt;p&gt;No .env file sits on disk to be picked up by a backup, an editor plugin, or a careless git add ..&lt;/p&gt;

&lt;p&gt;Already leaked a key?&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Rotate it at the provider first. This is the step that matters.&lt;/li&gt;
&lt;li&gt;Then remove it from history (git filter-repo or BFG), and force-push.&lt;/li&gt;
&lt;li&gt;Check the provider’s logs for use of the old key.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Which tool?&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;Small team, want it working in a minute: sealenv or dotenvx.&lt;/li&gt;
&lt;li&gt;Cloud KMS, compliance, or per-value YAML encryption: SOPS.&lt;/li&gt;
&lt;li&gt;Team already on 1Password: op run.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;sealenv is open source (MIT): &lt;a href="https://github.com/sozenka/sealenv" rel="noopener noreferrer"&gt;sealenv&lt;/a&gt;. If it’s useful to you, sponsoring keeps it maintained.&lt;/p&gt;

</description>
      <category>security</category>
      <category>rust</category>
      <category>devops</category>
      <category>opensource</category>
    </item>
  </channel>
</rss>
