Forem: Ayomide Adebisi

How to Store Secrets in the Mac Keychain (and Use Them Like Environment Variables)

Ayomide Adebisi — Sat, 28 Mar 2026 17:27:11 +0000

I used to keep API keys in .env because it was fast. Then I caught myself grepping my home folder for something unrelated and watching paths scroll past that file, or almost committing a backup copy. None of that is catastrophic every time, but it’s a bad habit. On a Mac you already have a place meant for secrets: Keychain.

This isn’t a pitch for a fancy secrets vault. It’s about the security tool that ships with macOS—handy for local dev tokens, DB URLs, signing keys, that sort of thing.

One thing to get straight up front: Keychain doesn’t literally store “environment variables.” It stores items (usually generic passwords) keyed by service name and account. You pull the value out with security and export it when you need it. Day to day it behaves like env vars; under the hood it’s a lookup, not a magic .env replacement.

You’ll need a Mac, a terminal, and if you want secrets to load automatically, willingness to touch ~/.zshrc or similar.

Save and read a secret

Add a generic password (Terminal may ask for Keychain permission the first time):

security add-generic-password \
  -a "$USER" \
  -s "myapp-dev-api-key" \
  -w "sk_live_xxxxxxxx"

-a — account; often your macOS username or an app name.
-s — service string; this is the handle you’ll use later. Make it unique, e.g. myapp-dev-api-key.
-w — the secret. The problem is anything after -w can land in shell history (see below).

Read it (prints to stdout):

security find-generic-password -s "myapp-dev-api-key" -w

Use it as an env var for this shell only:

export MYAPP_API_KEY="$(security find-generic-password -s "myapp-dev-api-key" -w)"

After that, anything that reads MYAPP_API_KEY behaves as if you’d sourced a .env—except the value never had to live in a plaintext file on disk.

Avoiding shell history when you add the secret

Apple’s own usage text says bluntly that -p / -w on the command line is insecure. Two patterns that actually work:

Built-in prompt (often the nicest): put -w last and omit the value. security will prompt for the password; that path doesn’t shove the secret into your history the way -w "secret" does.

security add-generic-password -a "$USER" -s "myapp-dev-api-key" -w

(When it asks, type or paste the secret; it’s the usual “no echo” style prompt.)

Shell-side prompt if you prefer to stay in bash/zsh:

printf 'Paste secret (hidden): '
read -rs SECRET
echo
security add-generic-password -a "$USER" -s "myapp-dev-api-key" -w "$SECRET"
unset SECRET

Keychain Access still counts: File → New Password Item… and line up the fields with whatever you pass as -a / -s so find-generic-password can find the item later.

Wiring it into how you actually work

Every new terminal (Zsh snippet in ~/.zshrc):

export MYAPP_API_KEY="$(security find-generic-password -s "myapp-dev-api-key" -w 2>/dev/null)"

2>/dev/null just keeps noise down if the item doesn’t exist yet.

Per project, a small scripts/load-secrets.sh that exports what that repo needs is reasonable—don’t commit values; document the service names in the README so someone else can add their own copy to Keychain.

One shot:

MYAPP_API_KEY="$(security find-generic-password -s "myapp-dev-api-key" -w)" uv run python -m myapp

What you gain, what you’re signing up for

You lose the plaintext secret sitting in .env (and in a lot of accidental greps and backups). It’s built in, no extra install, and Keychain can nudge or block access per app if you tune Access Control on the item. For “this laptop only” dev keys, that’s often plenty.

The flip side is boring but real: Linux and Windows won’t help you here—those teammates need 1Password CLI, Doppler, SOPS, cloud IAM, whatever your team standard is. There’s no automatic team sync; new machine usually means re-adding items (iCloud Keychain exists but that’s a deliberate trust choice). If you echo secrets or log them, you’ve undone the point. CI wants provider-native secrets, not interactive Keychain. Onboarding is also slightly worse than “copy .env.example”—people need the exact service strings and commands written down somewhere.

I still reach for this for solo Mac dev and small personal projects where I want fewer sensitive files lying around. For shared, audited, rotated secrets at work, use the thing your platform team points you at.

So: you store with security, load with export and $(security find-generic-password … -w), and you get env-var ergonomics without a plaintext .env for that value. The cost is macOS-only, a bit more documentation, and discipline around history and logging.

Cost Optimizations in AWS - Part 1

Ayomide Adebisi — Sun, 05 Jun 2022 14:14:33 +0000

I'm not really a fan of writing, but here i am still doing it.

Here are some tips i believe would be helpful with cost optimization on AWS

This are the steps i take to reduce my costs on aws cloud

1. EC2 Instance Type

When choosing an instance type for a particular workload, here are some questions to ask yourself

Questions to ask yourself ?

What is the use case for this workload ?

This question above helps you understand the need for the particular workload. This leads me to the questions below

What is the capacity Ram ,Cpu or Storage?
How often would the instance be utilized - would be instance be running a machine learning application. and needs more compute , would it just be running a light web application e.t.c ?

These questions helps you select the best instance to select on the basis of memory , cpu or ram usage,

2. Elastic IP's
Elastic IP addresses can actually add cost to your infrastructure when not in use. since IPv4 addresses are limited , it makes sense that AWS charges you for them when not in use and makes it free when in use. also note that attaching 2 EIP addresses to the same instance would still require AWS to charge you.

3. AWS Instance scheduler
https://aws.amazon.com/solutions/implementations/instance-scheduler/

Development services and other non-production services (instance and database) can be turned off when not in use.

This can be automated by using AWS Instance Scheduler which helps you automate the process of keeping your instances down based on your custom schedule (when you believe that no one is currently using the services). This can be done for a company running on a 9-5 basis that has a non-production instance and database running . The company can schedule the services by 5:30 pm daily and bring them back online by 8am the next morning. This would be fully automated by instance scheduler.

Adding EC2 instances and Database instances to instance scheduler can be done by tagging the instances with the created instance scheduler name

4. Autoscaling

if the autoscaling is frequent on your service (i.e you scale like 1 - 5 times in the hour), you might need to change your instance size to a more stable instance. This can help you reduce your costs and reduce the scaling frequency of your application during peak limits. Also if you understand the timing and trend of traffic into your service, you should look at scheduled scaling to help scale the service at periods of high traffic.

5. Spot instances

Spot instances can give a great reduction in cost because . Spot Instances are a cost-effective choice if you can be flexible about when your applications run and if your applications can be interrupted. For example, Spot Instances are well-suited for data analysis, batch jobs, background processing, and optional tasks.

6. Database

Use RDS serverless for non-production database instances with infrequent usage. RDS Serverless reduces the instances running the database when not being used, This dosen't mean that your database would not be running. This means that it would be in a sleep mode when no API calls have been made to the database for a while. when the database is in a sleep mode, the first call is usually a but slow before the database picks up the usual work pace. This is perfect for non-production environments. you only pay for what you use.

RDS Aurora : This is the best

Some AWS tools to give you more insights into your resources and services cost

AWS Trusted Advisor(based on past 30 days) Tells you about the following

Amazon reserved instance optimization
Idle load balancers
Underutilized EBS volumes
Unassociated EIP addresses
Idle RDS db instances
Amazon Route53 latency resource record sets
Underutilised Amazon Redshift Clusters