amureki.me

Safer local envs with 1Password and op run

Rust Saiargaliev — Thu, 18 Jun 2026 00:00:00 +0000

I kept too many secrets in my .env</code> files.</p>

The goal: run local commands without keeping sensitive environment variables in plaintext inside the project directory.</p>

This led me to looking for ways to be protected against:</p>


supply-chain attacks: a random dependency or tool reading local files;</li>
agentic workflows: coding agents accidentally seeing or exposing secrets from the workspace.</li>
</ul>
I already use a password manager for secrets. In my case, that is 1Password, and like many password managers it has a CLI integration.</p>
The CLI can read items from your vault and pass them to local commands without you copying values around. The part I care about here is op run</code>: it can start a process with environment variables resolved from 1Password.</p>
That means I can keep the local .env</code> workflow, but stop putting real secret values in the file:</p>
SECRET_KEY=op://dev/project/SECRET_KEY</span></span>
DATABASE_URL=op://dev/project/DATABASE_URL</span></span></code></pre>
Then op run</code> resolves those pointers only for the command it starts:</p>
op</span> run</span> --env-file</span> .env</span> --</span> uv run manage.py runserver</span></span></code></pre>
A nice side effect: reading the real values goes through 1Password. If something unexpected tries to resolve them, I get an unlock prompt first, which gives me a chance to stop and ask: "did I actually mean to give this command my secrets?"</p>
</p>
That is already enough, but I did not want to type the full command every time, so I wrapped it in a tiny zsh helper:</p>
opr</span>() {</span></span>
  op</span> run</span> --env-file</span> "${</span>OP_ENV_FILE</span>:-</span>.</span>env</span>}"</span> --</span> "</span>$@</span>"</span></span>
}</span></span></code></pre>
Now I can run my Django server like this:</p>
opr</span> uv run manage.py runserver</span></span></code></pre>
or a FastAPI app:</p>
opr</span> fastapi dev</span></span></code></pre>
The process still gets the environment it needs, but the secrets are managed by 1Password instead of sitting casually in the repository/worktree.</p>
Advanced: aliases</h2>
I am also quite lazy and like aliases</a>, so I wanted this to work too:</p>
alias</span> runserver</span>=</span>"uv run manage.py runserver"</span></span>
opr</span> runserver</span></span></code></pre>
The minimal opr</code> helper does not support that, because shell aliases are not executables. op run</code> tries to execute runserver</code> as a real command from $PATH</code>.</p>
To make opr</code> understand zsh aliases too, I expand the first argument before calling op run</code>:</p>
opr</span>() {</span></span>
  local</span> env_file</span>=</span>"${</span>OP_ENV_FILE</span>:-</span>.</span>env</span>}"</span></span>
  local</span> -a</span> cmd expanded</span></span>
  local</span> expansions</span>=</span>0</span></span>
</span>
  cmd</span>=</span>(</span>"</span>$@</span>"</span>)</span></span>
  while</span> (( $#</span>cmd</span> ></span> 0</span> &&</span> ${+</span>aliases</span>[</span>$cmd</span>[1]]}</span> &&</span> expansions</span> <</span> 20</span> ));</span> do</span></span>
    expanded</span>=</span>(${(</span>z</span>)</span>aliases</span>[</span>$cmd</span>[1]]})</span></span>
    cmd</span>=</span>(</span>"${</span>expanded</span>[</span>@</span>]}" "${</span>cmd</span>[</span>@</span>]</span>:</span>1</span>}"</span>)</span></span>
    ((</span>expansions</span>++</span>))</span></span>
  done</span></span>
</span>
  op</span> run</span> --env-file</span> "</span>$env_file</span>"</span> --</span> "${</span>cmd</span>[</span>@</span>]}"</span></span>
}</span></span></code></pre>
Then the lazy version works:</p>
opr</span> runserver</span></span></code></pre>Alternatives</h2>
This helper is intentionally tiny. If you are interested in the idea, but did not like my solution or want something more production-like, here are some alternatives:</p>

dotenvx</a>, which supports encrypted .env</code> workflows and stays close to the familiar dotenv model.</li>
Varlock</a>, which adds a committed .env.schema</code>, type/required metadata, redacted config checks, and secret leak scanning.</li>
git-secret</a>, which encrypts secret files before committing them to Git. Useful, but a different trade-off: after decrypting, you still have plaintext files in the worktree.</li>
</ul>
Devcontainers can also help by isolating the tooling that touches a project, but they do not remove the secrets problem by themselves: the container still needs those values from somewhere.</p>
These are bigger tools than my alias, but that can be the right trade-off for a team, especially if you want an explicit env contract for humans and agents.</p>
None of this protects you from code running inside the target process: that code can read its own environment. The win is smaller than that, but still useful: fewer plaintext secrets sitting around for tools, agents, or accidental commits to stumble over.</p>
I would not add this to every project by default. It is most useful when the same checkout is touched by lots of tools, scripts, or agents.</p>



Fast Keyboard Layout Switching on macOS
Rust Saiargaliev — Fri, 07 Mar 2025 00:00:00 +0000
For the longest time, switching input languages on my Mac was frustratingly slow.
The default Control + Space</em> shortcut had a nearly one-second delay</strong> before switching languages.
If you're a fast typist, that means typing the first few characters in the wrong language — super annoying.</p>
I tried every solution I could find:</p>

Custom AppleScripts.</li>
The unmaintained (but surprisingly still functional) open-source tool Kawa</a>.</li>
I even wrote my own Swift-based solution.</li>
</ul>
None of them fixed the actual problem — the delay itself</strong>.</p>
The Solution</h2>
After a lot of trial and error, I stumbled upon this in System Preferences → Keyboard → Shortcuts -> Input Sources</em>:</p>
</p>

The default shortcut for "Select the previous input source"</strong> (Control + Space</em>) has a delay.</li>
The shortcut for "Select next source in Input menu"</strong> (Control + Option + Space</em>) does not</em> have a delay.</li>
</ul>
For whatever reason, Apple made the slower one the default. The fix?</p>
Just swap the shortcuts.</em></strong></p>
Now, the Control + Space</em> shortcut switches input languages instantly,
and the Control + Option + Space</em> shortcut has the delay (who cares?).</p>
But why?</h2>
I still have questions:</p>

Why does the "previous" shortcut have a delay while the "next" one doesn’t?</li>
Why isn’t the faster shortcut the default?</li>
Is this a bug, a design choice, or just legacy behavior?</li>
</ul>
If you know the answer, I’d love to hear it.</p>
For Globe (🌐) icon lovers</h2>
In case you like are using Apple's keyboard with the Globe icon,
you may also experience a delay when switching input languages.
For you I found another hint:
In System Preferences → Keyboard → Shortcuts -> Mission Control</em> you can disable the shortcut for "Quick Note" (🌐Q)
which can cause the delay if you just want to switch the input language.</p>
</p>
Another example of some creativity ruining the user experience.</p>
Keep calm and typing fast!</p>


Disable `auto_now` and `auto_now_add` in Django migrations
Rust Saiargaliev — Fri, 27 Sep 2024 00:00:00 +0000
Django's DateField</code> and DateTimeField</code> fields have two options that can be set to automatically set the field to the current date and time when a new record is created or updated:</p>

auto_now</code>: Automatically sets the field to the current date and time every time the record is saved.</li>
auto_now_add</code>: Automatically sets the field to the current date and time when the record is first created.</li>
</ul>
A common use case for these options is setting created_at</code> and updated_at</code> fields in a model:</p>
from</span> django.db</span> import</span> models</span></span>
</span>
class</span> Article</span>(</span>models</span>.</span>Model</span>):</span></span>
    title</span> =</span> models.</span>CharField</span>(</span>max_length</span>=</span>255</span>)</span></span>
    created_at</span> =</span> models.</span>DateTimeField</span>(</span>auto_now_add</span>=</span>True</span>)</span></span>
    updated_at</span> =</span> models.</span>DateTimeField</span>(</span>auto_now</span>=</span>True</span>)</span></span></code></pre>
However, if you want to migrate some data you might stumble into a problem.</p>
from</span> django.db</span> import</span> migrations, models</span></span>
</span>
def</span> create_old_article</span>(</span>apps</span>,</span> schema_editor</span>):</span></span>
    Article</span> =</span> apps.</span>get_model</span>(</span>'blog'</span>,</span> 'Article'</span>)</span></span>
    </span></span>
    old_article</span> =</span> {</span></span>
        'title'</span>:</span> 'My old article'</span>,</span></span>
        'created_at'</span>:</span> '2020-01-01 12:00:00'</span>,</span></span>
        'updated_at'</span>:</span> '2024-01-01 12:00:00'</span>,</span></span>
    }</span></span>
</span>
    Article.objects.</span>create</span>(**old_article)</span></span>
</span>
class</span> Migration</span>(</span>migrations</span>.</span>Migration</span>):</span></span>
      dependencies</span> =</span> [</span></span>
          (</span>'blog'</span>,</span> '0001_initial'</span>),</span></span>
      ]</span></span>
</span>
      operations</span> =</span> [</span></span>
          migrations.</span>RunPython</span>(create_old_article),</span></span>
      ]</span></span></code></pre>
Running this migration would set created_at</code> and updated_at</code> to the current date and time, not the specified historical dates.</p>
To preserve the historical dates during migration, you can temporarily disable the auto_now</code> and auto_now_add</code> behavior:</p>
...</span></span>
</span>
def</span> create_old_article</span>(</span>apps</span>,</span> schema_editor</span>):</span></span>
    Article</span> =</span> apps.</span>get_model</span>(</span>'blog'</span>,</span> 'Article'</span>)</span></span>
    </span></span>
    old_article</span> =</span> {</span></span>
        'title'</span>:</span> 'My old article'</span>,</span></span>
        'created_at'</span>:</span> '2020-01-01 12:00:00'</span>,</span></span>
        'updated_at'</span>:</span> '2024-01-01 12:00:00'</span>,</span></span>
    }</span></span>
</span>
    # Disable the auto_now and auto_now_add behavior</span></span>
    Article._meta.</span>get_field</span>(</span>'created_at'</span>).auto_now_add</span> =</span> False</span></span>
    Article._meta.</span>get_field</span>(</span>'updated_at'</span>).auto_now</span> =</span> False</span></span>
</span>
    Article.objects.</span>create</span>(**old_article)</span></span>
    </span></span>
    # Re-enable the `auto_now` and `auto_now_add` behavior </span></span>
    #  in case there are other operations within the migration</span></span>
    Article._meta.</span>get_field</span>(</span>'created_at'</span>).auto_now_add</span> =</span> True</span></span>
    Article._meta.</span>get_field</span>(</span>'updated_at'</span>).auto_now</span> =</span> True</span></span>
</span>
...</span></span></code></pre>
This approach disables the automated logic for the duration of the migration, allowing the fields to be set to the specified values.</p>


Heroku CLI aliases
Rust Saiargaliev — Sun, 17 Mar 2019 00:00:00 +0000
Heroku has nice and powerful CLI</a>, which I am using quite heavily for company and personal stuff almost every day.</p>
Very often I need to log in to one of my apps or to the addons, but default commands are very verbose, so here are my shorter aliases:</p>
# Heroku</span></span>
alias</span> heroku-login</span>=</span>"heroku login"</span></span>
alias</span> heroku-logs</span>=</span>"heroku logs -t"</span></span>
alias</span> heroku-bash</span>=</span>"heroku run bash"</span></span>
</span>
## Addons</span></span>
alias</span> heroku-cloudamqp</span>=</span>"heroku addons:open cloudamqp"</span></span>
alias</span> heroku-newrelic</span>=</span>"heroku addons:open newrelic"</span></span>
alias</span> heroku-scheduler</span>=</span>"heroku addons:open scheduler"</span></span>
alias</span> heroku-librato</span>=</span>"heroku addons:open librato"</span></span>
alias</span> heroku-logentries</span>=</span>"heroku addons:open logentries"</span></span>
alias</span> heroku-connect</span>=</span>"heroku addons:open herokuconnect"</span></span>
</span>
## Django-related</span></span>
alias</span> heroku-shell-plus</span>=</span>"heroku run python manage.py shell_plus"</span></span>
alias</span> heroku-dbshell</span>=</span>"heroku run python manage.py dbshell"</span></span></code></pre>


Revoke third-party access
Rust Saiargaliev — Thu, 10 Aug 2017 00:00:00 +0000
Somewhere in a Twitter, I found a couple of links to social networks settings
and advice to check the list of third-party services, which have access to your account.
I started going through my social accounts and cleaning there.</p>
That was a horrible mess, sometimes I did not recognize what is this service
is used for and why I gave it permissions.</p>
So, I've just decided to keep a list of links to social accounts settings,
so I can revisit it sometimes and clean up again.</p>
Here is a link to it: https://amureki.me/revokeaccess/</a>
(GitHub</a>)</p>


How GitHub uses GitHub to develop and deploy GitHub
Rust Saiargaliev — Fri, 21 Oct 2016 00:00:00 +0000
So, the talk was from Johannes Nicolai from Enterprise Solutions Engineering team. There were almost no marketing stuff, but about their inner structure and flow.</p>
Company-wise they have around 600 people, half of them working remotely from everywhere, half of them based in San Francisco. And they are operating the 51st popular website on the internet.</p>
They are doing everything over GitHub, like literally everything. Marketing, finance, legal and agreements teams all using only GitHub and markdown for issues, documents reviewing and stuff. They all against email - want to be everything documented on GitHub, so if in case it could be pointed to right issue or discussion.</p>
An interesting thing - even for documents and non-code repositories, they have different CI checks and linters, for example for the blog they have text errors, buzzwords, passive-aggressive style checks (around 10-16 different linters only for text).</p>
They are doing around 500 deploys per week. All devops stuff - deployments, metrics, changing some devops configurations, increasing limits they are doing via hubot in Slack. If something is going wrong, for example, DDoS, online team is talking about it and doing some performance checks and fixes right in Slack commands - that helps to see in the future what happened and what was done to check it and to fix it (also helps other people to learn how to be in that kind of situations).</p>
GitHub's engineers have deployment timeline - you can see if there were increased errors rate or some spikes, you see after which PRs that happened, who made it, who fixed it.</p>
If you want to deploy your feature (from feature-branch only), you are queuing up for it in Slack, hubot will notify when you can deploy a feature, notify where you can deploy it and here you go. If you’re ready for production, first your branch goes for canary-production (for a small part of the servers), then after 5-15 minutes, it goes for all servers. Only after that, your branch is merged to main. :)</p>
Also, they are actively using feature-flags, so deployed features they can turn on for themselves/certain teams/some repositories/part of end users.</p>
Some useful links:</h4>

FutureStack15: Changing the Laws of Engineering with Pull Requests (talk from New Relic)</a></li>
Hubot - chatops bot used in GitHub</a></li>
GitHub Engineering Blog</a></li>
Package for feature-flags</a></li>
</ul>


Количество строк кода в Django-проекте
Rust Saiargaliev — Tue, 20 Jan 2015 00:00:00 +0000
Составил недавно небольшую команду для подсчета количества строчек полезного (более или менее) кода в своих Django-проектах.</p>
find</span> .</span> -name</span> "*.py"</span> -type</span> f !</span> -path</span> '*/migrations/*'</span> -exec</span> grep . {}</span> \;</span> |</span> wc</span> -l</span></span></code></pre>
Коротко про команду: берем все файлы с расширением .py</code>, исключаем папки миграций, после чего уже внутри самих файлов считаем все не пустые строчки.</p>
Update: Нашел cloc</a> - отличная утилитка для подробного подсчета количества строчек в проектах для разных языков программирования.</p>


Регистрация при восстановлении пароля
Rust Saiargaliev — Sat, 17 Jan 2015 00:00:00 +0000
На одном из сервисов недавно возникла ситуация: в поддержку пришло письмо, с жалобой пользователя, которому не приходит письмо для восстановления пароля.</p>
После короткой проверки выяснил, что такого пользователя просто нет в системе.</p>
И в голову пришла мысль, а почему бы не регистрировать пользователей, которые по какой-либо причине считают что уже имеют аккаунт на сайте? Их цель - получить свой пароль и зайти на сервис, так давайте позволим им это.</p>

amureki.me

Safer local envs with 1Password and op run

Alternatives</h2> This helper is intentionally tiny. If you are interested in the idea, but did not like my solution or want something more production-like, here are some alternatives:</p>

Fast Keyboard Layout Switching on macOS

Disable `auto_now` and `auto_now_add` in Django migrations

Heroku CLI aliases

Revoke third-party access

How GitHub uses GitHub to develop and deploy GitHub

Some useful links:</h4> FutureStack15: Changing the Laws of Engineering with Pull Requests (talk from New Relic)</a></li> Hubot - chatops bot used in GitHub</a></li> GitHub Engineering Blog</a></li> Package for feature-flags</a></li> </ul>

Количество строк кода в Django-проекте

Регистрация при восстановлении пароля

Some useful links:</h4>

FutureStack15: Changing the Laws of Engineering with Pull Requests (talk from New Relic)</a></li>
Hubot - chatops bot used in GitHub</a></li>
GitHub Engineering Blog</a></li>
Package for feature-flags</a></li> </ul>