Erdinç Yaşan

Storing credentials in the repo: SOPS + age

2026-08-14T00:00:00+00:00

On one of my projects there was a question I kept hitting during deployment: where should I keep the secret values? At first I stored them as GitHub secrets. It worked fine, but over time reading them back became a hassle.

My first approach was to put the whole .env</code> file into a single GitHub secret. It was easy, but this time I couldn't see which secret was actually set: everything was one block. If instead I made each value a separate secret, then as the number of secrets grew I had to set dozens of values one by one, a management headache of its own.

I could also have kept a secret file directly on the server. But then I'd have to connect to the server for every change. I clarified what I wanted: to change a secret and deploy it automatically, without touching the CI process at all.

After some research I came across a method the Mozilla team put out: SOPS. Combined with age, I could keep the secrets encrypted inside the repo itself. Wherever the code is, the secret is right there too, but not as plaintext. In this post I explain how I did it, where it works well, and where you need to be careful.

All the examples are in a working demo repo: https://github.com/erdyasan/sops-age-example

The idea</h2>
There are two pieces:</p>

age</strong>: a simple, modern encryption tool. We generate a public/private key
pair. What is encrypted with the public key can only be opened with the private
key.</li>
SOPS</strong> (Secrets OPerationS): it encrypts only the values</strong> of a
YAML/JSON/env file, leaving the keys (the field names) in the clear. So the
file still stays in a readable shape, but the values are encrypted. When we take
a diff we can see "which field changed", but not the value itself.</li>
</ul>
age works with asymmetric keys: we generate a public/private key pair. We encrypt
the data with the public key</strong>, and that data can only be opened with the
matching private key</strong>, no other key. That's where the asymmetry is: we can
hand the public key to everyone, anyone can prepare encrypted data for us with it,
but the only party who can open it is the owner of the private key. So being able
to encrypt is a capability open to everyone, while decrypting is in a single hand.
(GPG basically works with the same asymmetric logic: encrypt with public, open
with private.)</p>
age's difference from GPG is in weight. GPG (GNU Privacy Guard) is powerful but
heavy: a trust model called the web-of-trust, keyring management, keyservers, key
expiry dates, subkeys, agent processes running in the background, dozens of
subcommands. There's quite a bit of concept to learn before you even encrypt a
file. age is focused on a single job: no config file, short keys, one-line
commands. For everyday secret encryption you rarely need all of GPG's machinery;
age does the same job far more plainly.</p>
Putting these together, we get this: the secret file can be committed to git.
Because the values inside it are encrypted with age. Someone who clones it without
the private key sees only a useless piece of ciphertext. Who changed what and when
stays in the git history. On a new machine everything comes with a single
git clone</code> (plus the age key).</p>
Let me say this upfront: this approach is a perfect fit for small and mid-sized
projects. But it has a limit. Because the public keys are out in the open in
.sops.yaml</code>, anyone with write access to the repo, even if they can't read the
values of the secrets, can write new values over them (I explain this below in
the "Being able to encrypt is not being able to read" section). In a small and
trusted team this is an acceptable risk. As the team and the blast radius grow,
you need extra protections on the git side (branch protection, mandatory review,
rules specific to the secret path) or, past a certain point, a centralized secret
manager.</p>
Setup</h2>
On macOS both are in brew:</p>
brew</span> install</span> sops</span> age</span></span></code></pre>1. Generate an age key</h2>
age-keygen</span> -</span>o</span> key.txt</span></span></code></pre>
Its output is a file like this:</p>
# created: 2026-08-12T12:02:42+03:00</span></span>
# public key: age1cpyuq5ss7w85phtrkhsxntek7k4ypx3gr8qa8c4vd5y0k772wqssrd4w4q</span></span>
AGE-SECRET-KEY-1DC8QTSCYAXRADPLAQA853TMCYDYZXSJ9JW8MFWRYLZFM6J4E67CS3K6ZW5</span></span></code></pre>
The top age1...</code> line is the public key</strong> (recipient). The bottom
AGE-SECRET-KEY-...</code> is the private key</strong>. We encrypt with the public key, we
open with the private key. The private key stays secret, and we can share the
public key freely. In practice the private key lives on each machine under
~/.config/sops/age/keys.txt</code> and is never committed.</p>
2. File layout: secrets/ and .env.enc</h2>
In my own setup I keep the secrets in a secrets/</code> directory, separated per
environment. There are three files per environment:</p>
secrets/</span></span>
  app.local.env.enc         # encrypted, committed</span></span>
  app.local.env.example     # keys only, committed (so which secrets exist is clear)</span></span>
  app.local.env             # plaintext working file, GITIGNORE (local, decrypted copy)</span></span></code></pre>
The logic is this: .enc</code> is the encrypted, committed file; .example</code> is the
template that carries only the key names, which a newcomer looks at to see "which
values do I need to fill in"; and the plain .env</code> is the decrypted copy created
while editing, which stays in .gitignore</code> and is never committed.</p>
Another benefit of the .enc</code> extension is on the CI side: the pipeline can find
all the encrypted files at once with a pattern like secrets/*.env.enc</code> and
decrypt them in bulk. The *</code> here is a wildcard character; it means "bring me all
the file names that match this pattern". Matching file names by a pattern like
this is called globbing (everything in secrets/</code> that ends with .env.enc</code>). The
extension is also a signal that says "this file is encrypted, it will be decrypted
at deploy".</p>
One point: the .enc</code> extension doesn't tell SOPS the format. The files are in
dotenv (KEY=value</code>) format, but since SOPS can't infer that from the extension,
you have to pass the format by hand on every command: --input-type dotenv --output-type dotenv</code>. The little manager below always adds this automatically.</p>
3. Who it's encrypted for: .sops.yaml</h2>
.sops.yaml</code> tells SOPS which file to encrypt for whom. We define different
recipients per environment. First we write the keys once as anchors and reference
them below:</p>
#</span> .sops.yaml</span></span>
k</span>eys</span>:</span></span>
  -</span> &</span>local</span>          a</span>ge1cpyuq5ss...</span>   #</span> my machine</span></span>
  -</span> &</span>server_staging</span> a</span>ge12clzmdhl...</span>   #</span> staging server</span></span>
  -</span> &</span>server_prod</span>    a</span>ge1g5uwzup8...</span>   #</span> prod server</span></span>
</span>
c</span>reation_rules</span>:</span></span>
  #</span> local: only my machine can open</span></span>
  -</span> p</span>ath_regex</span>:</span> s</span>ecrets[/\\]app\.local\.env(\.enc)?$</span></span>
    k</span>ey_groups</span>:</span></span>
      -</span> a</span>ge</span>:</span></span>
          -</span> *</span>local</span></span>
</span>
  #</span> staging: staging server + me</span></span>
  -</span> p</span>ath_regex</span>:</span> s</span>ecrets[/\\]app\.staging\.env(\.enc)?$</span></span>
    k</span>ey_groups</span>:</span></span>
      -</span> a</span>ge</span>:</span></span>
          -</span> *</span>server_staging</span></span>
          -</span> *</span>local</span></span>
</span>
  #</span> prod: prod server + me</span></span>
  -</span> p</span>ath_regex</span>:</span> s</span>ecrets[/\\]app\.prod\.env(\.enc)?$</span></span>
    k</span>ey_groups</span>:</span></span>
      -</span> a</span>ge</span>:</span></span>
          -</span> *</span>server_prod</span></span>
          -</span> *</span>local</span></span></code></pre>
The recipient model here matters: each environment is encrypted with that
environment's server public key + my local public key</strong>. The result:</p>

The server opens it at deploy time with its own private key.</li>
I open and edit it locally with my own private key.</li>
Only the prod server (and me) can open the prod file; the staging server or
another developer can't decrypt the prod secret, because their key isn't in that
rule.</li>
</ul>
All the age1...</code> lines we write in .sops.yaml</code> are public keys</strong>. No private
key goes in here.</p>
For a while I set up sops+age a bit by rote; I didn't fully know how this
structure works. Back then I hadn't read the whole documentation, and honestly I
had no experience either. Later I realized that key_groups</code> here is actually a
term that needs care: the moment we say "encrypt for local too" in the prod rule,
the prod secret becomes decryptable on local as well. When SOPS encrypts a value
it first generates a random data key, encrypts the actual data with it, then wraps
that data key separately for each recipient's public key in the group. So the data
key in the prod file can be opened both with the prod server's private key and
with my local private key; either one is enough. When I saw that I could decrypt
the prod secrets locally with sops -d</code>, honestly I was quite surprised; my first
thought was "is there a vulnerability here?". There isn't: this is exactly the
result of my adding &local</code> to every environment's key group, the design itself.
The same holds for staging/qa: as long as &local</code> is a recipient in the rule, I
can open that environment locally.</p>
But you need to see the trade-off it brings: someone who gets hold of the local
private key can decrypt the secrets of every environment (prod included) where
that key is a recipient. So it matters to protect the keys.txt</code> file and to
choose deliberately who is a recipient for which environment. In a small and
trusted team this is an acceptable convenience. If we want to narrow access, we
take local out of the prod group and encrypt prod with only the server key; then
no one can open the prod secret locally.</p>
(The secrets[/\\]</code> in path_regex</code> covers both the /</code> and \</code> separator: a
Windows portability detail, which I touch on in the encoding section below.)</p>
A terminology note too: key_groups</code> here is just a container that wraps
recipients within a single group. For environment separation, a single group and
the recipient list we write into it are enough.</p>
Full file:
https://github.com/erdyasan/sops-age-example/blob/811a70873d040b2be83f68f5cfaaf972cef7deeb/.sops.yaml</p>
4. Write and encrypt the secret</h2>
First we prepare the plain working file (dotenv):</p>
# secrets/app.local.env  (gitignored, plaintext)</span></span>
HELLO=world</span></span>
FAKE_API_KEY=demo_local_sk_0000</span></span>
DB_PASSWORD=local-demo-password</span></span></code></pre>
Then we encrypt it (passing the dotenv format by hand):</p>
sops</span> -</span>e</span> -</span>-input-type</span> dotenv</span> -</span>-output-type</span> dotenv</span> secrets/app.local.env</span> ></span> secrets/app.local.env.enc</span></span></code></pre>
The .enc</code> file now looks like this:</p>
HELLO=ENC[AES256_GCM,data:wPU91TF7...,iv:bbS2qHGd...,tag:ALssHW9H...,type:str]</span></span>
FAKE_API_KEY=ENC[AES256_GCM,data:...,type:str]</span></span>
DB_PASSWORD=ENC[AES256_GCM,data:...,type:str]</span></span>
sops_age__list_0__map_recipient=age1cpyuq5ss...</span></span>
sops_mac=ENC[AES256_GCM,...]</span></span>
sops_version=3.13.2</span></span></code></pre>
The field names (HELLO</code>, FAKE_API_KEY</code>, DB_PASSWORD</code>) are in the clear, their
values encrypted. That's exactly why the diffs stay meaningful. The sops_...</code>
lines at the bottom are SOPS's metadata: which recipient it was encrypted for and
the integrity check (mac</code>). If we used YAML this would be a sops:</code> block; since
dotenv holds plain key=value, the metadata is also spread across plain keys as
sops_...</code>.</p>
We can commit this .enc</code> file without worry. The plain app.local.env</code>, on the
other hand, git doesn't see.</p>
5. Decrypting at runtime</h2>
The encrypted file is nice, but how will the application read it? The cleanest way
is to never write the plaintext to disk at all: decrypt the file in memory and
inject the values into the process as environment variables.</p>
For this I put a small manager in the repo (secrets.mjs</code>), a simplified version
of the more thorough one in my real project. It doesn't roll its own crypto, it
just calls the sops</code> CLI. The run</code> command decrypts the environment and runs the
given command with those variables:</p>
node</span> secrets.mjs</span> run</span> local</span> -</span>-</span> node</span> index.js</span></span></code></pre>
The application side just reads process.env</code>, it doesn't even know about SOPS:</p>
//</span> index.js</span></span>
const</span> KEYS</span> =</span> [</span>"</span>HELLO</span>"</span>,</span> "</span>FAKE_API_KEY</span>"</span>,</span> "</span>DB_PASSWORD</span>"</span>]</span>;</span></span>
</span>
console</span>.</span>log</span>(</span>"</span>Secrets decrypted by SOPS, read from process.env:</span>\n</span>"</span>)</span>;</span></span>
for</span> (</span>const</span> key</span> of</span> KEYS</span>)</span> {</span></span>
  console</span>.</span>log</span>(</span>`</span>  ${</span>key</span>}</span> = </span>${</span>process</span>.</span>env</span>[</span>key</span>]</span> ??</span> "</span>(missing)</span>"</span>}</span>`</span>)</span>;</span></span>
}</span></span></code></pre>
Output:</p>
$ npm start</span></span>
</span>
Secrets decrypted by SOPS, read from process.env:</span></span>
</span>
  HELLO = world (local)</span></span>
  FAKE_API_KEY = demo_local_sk_0000_not_a_real_key</span></span>
  DB_PASSWORD = local-demo-password</span></span></code></pre>
Why my own little script instead of sops exec-env</code>? Because exec-env</code> doesn't
accept the --input-type</code> flag; since it can't infer the format from the
extension, it doesn't work with extensionless/.enc</code> dotenv files. On the Node
side, decrypting with sops -d --input-type dotenv ...</code> and parsing the output
both solves this problem and keeps the shell from mangling values that contain
spaces (like world (local)</code>). The decrypted content is never written to disk, it
only stays in memory as long as the process is alive.</p>
The full manager:
https://github.com/erdyasan/sops-age-example/blob/811a70873d040b2be83f68f5cfaaf972cef7deeb/secrets.mjs</p>
Team: not sharing a key, but adding a recipient</h2>
At the start we generated a single key pair, because we were a single person. So
what happens when it becomes a team, do we hand everyone the same private key? No.
The trick is exactly here.</p>
Each person on the team runs age-keygen</code> on their own machine and generates a
pair of their own: their own private key (secret, never leaves their machine) and
their own public key (shareable). So there isn't a single public key out there;
every member has a different pair. All the age1...</code> lines in .sops.yaml</code> are
public keys.</p>
Here's how SOPS works when it encrypts a file: it generates a random data key,
encrypts the actual values with it, then wraps this data key separately with each
recipient's public key in that rule. So anyone (or any server) in the list can
open the data key with their own private key and decrypt the file. Since everyone
has a separate private key, no one needs to know anyone else's key.</p>
Why this way? Because if we handed a single private key to everyone: when one of
them leaked it, they'd all burn at once, you couldn't tell who opened what, and to
change the key we'd have to redistribute it to everyone. When they're separate,
only the public keys are shared, and the private keys never leave the machine.</p>
When someone new joins, we add their public key to the relevant rule, then, to
wrap the file for them too:</p>
sops</span> updatekeys</span> secrets/app.local.env.enc</span></span></code></pre>
When someone leaves: we remove their public key from .sops.yaml</code>, run sops updatekeys</code>, and also rotate the actual secret values. (The person who left can
still open the encrypted file in an old commit, because that version stays in the
history. That's why changing the value is a must.)</p>
CI (GitHub Actions)</h2>
In the CI environment we provide that environment's private key as a repo secret:</p>
-</span> r</span>un</span>:</span> n</span>ode secrets.mjs run prod -- node index.js</span></span>
  e</span>nv</span>:</span></span>
    S</span>OPS_AGE_KEY</span>:</span> $</span>{{ secrets.PROD_AGE_KEY }}</span></span></code></pre>
SOPS_AGE_KEY</code> takes the key's content directly; SOPS_AGE_KEY_FILE</code> instead wants
a file path. That's exactly what I wanted: without touching CI at all, I update a
secret by committing the encrypted file, and since the prod key lives only in the
prod CI's secret, environment isolation isn't broken.</p>
Being able to encrypt is not being able to read: repo access</h2>
At some point I realized this: the public keys are out in the open in
.sops.yaml</code>. So can someone with write access to the repo change the secrets?
Yes, they can. Encrypting needs only the public key, no private key. So that
person can't read</strong> the existing values (reading requires the private key), but
they can write new values over them, re-encrypt, and commit. Since at deploy the
server decrypts and uses the committed value, someone with write access can set
DB_PASSWORD</code> to a different value or point an API address to the wrong place.</p>
So SOPS gives us confidentiality</strong>, not integrity</strong>. It protects against
reading the values, not against changing them. In a small project this is usually
enough; as scale grows you need to close this gap on the git side. If you decide
to use sops in a team, my recommendation is these few measures:</p>


Branch protection + mandatory review.</strong> Close off direct push to main</code>, take
every change via PR + approval. That way no one can write over a secret and send
it to deploy on their own.</p>
</li>

Reviewer specific to the secret path (CODEOWNERS).</strong> Make certain people's
approval mandatory on every PR that touches secrets/</code> and .sops.yaml</code>.</p>
</li>

Automatic warning on the PR.</strong> Drop an automatic warning comment on a PR when
it opens touching the secret files. That way the change doesn't slip past the
reviewer's eye easily. If we want, we can tie this to a required status check to
block merges without approval, and go further with commit signing.</p>
</li>
</ul>
Note: the mac</code> field in SOPS catches manual (non-sops) tampering with the file,
but someone who properly re-encrypts with sops produces a valid mac</code>. So mac</code>
prevents a blind hex edit, not a re-encryption by an authorized person.</p>
Something to watch out for: metadata leaks</h2>
SOPS encrypts only the values</strong>, the field names stay in the clear</strong>. It's
this way so that diffs stay readable, but there's a cost: someone looking at the
file sees which secrets are being talked about. DB_PASSWORD</code>, STRIPE_SECRET_KEY</code>,
ADMIN_TOKEN</code>... the values are secret but the names give away the shape of the
infrastructure. If the field name itself is sensitive, you either encrypt the
whole file or neutralize the name.</p>
The line ending (CRLF/LF) and encoding trap</h2>
I struggled quite a bit with this on the deploy side, this was the most
infuriating part. I created the .enc</code> file on one machine (mac, LF line endings),
then opened the same repo on Windows. The values were correct but decryption just
wouldn't happen. The reason: SOPS computes a mac</code> (integrity check) over the
content for each file. When the bytes change even a little, the mac doesn't match
and the file is considered corrupted. On Windows there are a few separate things
that change these bytes.</p>
1. Git autocrlf.</strong> On Windows, git can convert LFs to CRLF during checkout. The
.enc</code>'s bytes change, the mac blows up. The fix is to turn off the conversion for
these files with .gitattributes</code>:</p>
# .gitattributes</span></span>
secrets/*.enc -text</span></span></code></pre>
-text</code> tells git "don't treat these files as text, don't touch the line
endings".</p>
2. PowerShell ></code> redirection writes UTF-16.</strong> This one took time to find. On
Windows, when you do sops -e ... > file.enc</code>, PowerShell's ></code> operator writes the
output as UTF-16 LE</strong>, not UTF-8, and adds a BOM on top. The file is born
corrupted from the start. A BOM inserted by editors gives the same result.</p>
That's why I wrote a small PowerShell script for Windows (encrypt.ps1</code>). Roughly:
it first normalizes the plaintext to LF-only + UTF-8 no BOM, then takes the sops
output into a variable rather than via ></code> and writes it with the .NET File API
(again LF + UTF-8 no BOM, a single trailing newline), and finally looks at the
file's first bytes and throws if there's a UTF-16/UTF-8 BOM or CRLF. So it makes
producing a corrupted .enc</code> impossible from the start. All of it is in the repo:
https://github.com/erdyasan/sops-age-example/blob/811a70873d040b2be83f68f5cfaaf972cef7deeb/encrypt.ps1</p>
3. Path separator.</strong> A small but annoying other Windows difference is the
path_regex</code> in .sops.yaml</code>. sops passes the file path to the regex as the OS
gives it; on Windows the separator is \</code>, so a pattern written only with /</code>
doesn't match and the file's "which rule it belongs to" can't be found. The reason
I wrote path_regex</code> as secrets[/\\]...</code> in the .sops.yaml</code> example above is
this: the bracket covers both separators.</p>
In short: the bytes of the .enc</code> files must be preserved exactly. Line endings,
encoding, BOM, anything that gets in between breaks the mac. You shouldn't open and
save the .enc</code> by hand in an editor; we always edit through the tools (sops,
secrets.mjs, encrypt.ps1). The encoding of the files matters.</p>
When SOPS, when the alternatives</h2>

git-crypt</strong>: encrypts the whole file, works transparently (opens on
checkout). But since it's file-based rather than value-based, the diffs are
unreadable. An advantage if we don't want field-name leakage.</li>
Vault / cloud secret manager (Azure Key Vault, AWS Secrets Manager)</strong>:
centralized, audit-logged, heavy solutions that generate dynamic secrets. The
right place if you have a large team and strict compliance requirements. But
standing them up and operating them is costly.</li>
SOPS + age</strong>: the sweet spot for small/mid projects. No extra service, the
secret is versioned in the same place as the code, setup is a handful of
commands. It also fits GitOps flows well.</li>
</ul>
One might ask, "We already have a private repo, isn't encrypting on top of it
unnecessary?" I don't think so: defense in depth. If the repo accidentally goes
public, if a fork leaks, or if someone's GitHub token is stolen, a plain .env</code> is
compromised instantly; the encrypted file is still useless without the private
key.</p>
Conclusion</h2>
Keeping secrets encrypted in the repo largely removes the "store the secret
somewhere separate" hassle. With SOPS + age the setup is a few commands, and daily
use is almost invisible. On small projects it provides a reasonable level of
security and a comfortable workflow without needing Vault.</p>
The full working demo, with all its files:
https://github.com/erdyasan/sops-age-example</p>



Free Custom Domain Email with Cloudflare and Gmail
2026-08-10T00:00:00+00:00
Sending email from a custom domain looks more professional. Most hosting
companies even offer it as a plus feature. But setting up and dealing with your
own email server is genuinely a hassle. It drags in SPF records, domain
verification, even reverse DNS. There are MX records too. So if you want your
mail to be delivered properly, there is a whole pile of settings to wrestle with.</p>
Most companies handle all of this for you automatically, of course. But the
moment you want a custom email service, these challenges show up.</p>
Anyway. Recently I decided to keep my website static, so I have no admin panel.
In short, there is no hosting or VPS running in the background, which means I have
no server cost. When I looked into how to handle email sending for the sake of a
professional identity/image, I saw that Gmail lets you send mail as another
person. I was already using mail forwarding on Cloudflare: for example, if you
send a mail to iam@erdincyasan.com</code>, it lands in my personal account,
erdincyasan@gmail.com</code>.</p>
Now let's go through how I set all this up.</p>
Prerequisites</h2>

Your domain's DNS must be managed on Cloudflare (the nameservers point to
Cloudflare).</li>
A Gmail account.</li>
Two-step verification (2FA) enabled on the Gmail account. This is required to
generate an app password, which I'll get to.</li>
</ul>
Step 1: Receiving mail with Cloudflare Email Routing</h2>
In the Cloudflare dashboard, select your domain and go to Email > Email
Routing</strong> in the left menu. If you're opening it for the first time, it walks you
through a setup flow.</p>
You do two things:</p>


Add a destination address.</strong> You tell it where the mail should land, that is
your own Gmail address (erdincyasan@gmail.com</code>). Cloudflare sends a
verification mail there; you click the link and confirm the address. Forwarding
won't work until you confirm.</p>
</li>

Add a routing rule.</strong> For example, everything sent to iam@erdincyasan.com</code>
should go to erdincyasan@gmail.com</code>. You can write a rule per address, or turn
on catch-all</strong> (whatever comes to the domain all goes into a single inbox).
Catch-all is practical but it also collects spam, so keep that in mind.</p>
</li>
</ol>
When you enable Email Routing, Cloudflare adds the required DNS records on your
behalf automatically. You don't need to touch them by hand, but it's good to know
what gets added:</p>

Three MX</strong> records (like route1.mx.cloudflare.net</code>, route2...</code>,
route3...</code>, with different priority values). These are the records that say
"this domain's mail should come here".</li>
One SPF</strong> record (TXT): v=spf1 include:_spf.mx.cloudflare.net ~all</code>.</li>
And a DKIM</strong> record (TXT, like cf2024-1._domainkey...</code>). This is a signing
record for Cloudflare's own mail path; it doesn't help mail sent from Gmail,
which I'll touch on in the "Limits" section below.</li>
</ul>
That's it. Now mail sent to iam@erdincyasan.com</code> lands in your Gmail. Test it:
send a mail to this address from another account and check whether it arrives in
Gmail.</p>
Step 2: Generating a Gmail app password</h2>
Now we move to the outbound side. You can't connect to SMTP with your normal
Gmail password; Google rejects it. Instead you generate a 16-character special
password called an app password</strong>.</p>
The prerequisite for this is having 2FA enabled. If 2FA is off, the app password
screen doesn't show up at all.</p>

Go to your Google account: Google Account > Security</strong>.</li>
If two-step verification isn't on, turn it on first.</li>
Then go to the App passwords</strong> section (if you type "app passwords" into the
search box you'll find it directly).</li>
Create a new app password and give it a name (say "Gmail SMTP").</li>
Google gives you a 16-character code that appears with spaces (like
abcd efgh ijkl mnop</code>). Save this code somewhere; once you leave the screen it
won't show it again.</li>
</ul>
There's a point here: Google shows the password with spaces between the groups,
but when you enter it into the SMTP settings you need to remove those spaces and
type it as one continuous string. Keep this in mind while filling in the SMTP
server details in Step 3, otherwise the password won't be accepted.</p>
Step 3: Introducing the custom address to Gmail (Send mail as)</h2>
The last step is telling Gmail "I can also send from this address".</p>

Gmail > Settings (gear) > See all settings > Accounts and Import</strong>.</li>
In the Send mail as</strong> section, click Add another email address</strong>.</li>
Enter a name and the address you want to send from: iam@erdincyasan.com</code>.</li>
The Treat as an alias</strong> checkbox appears. You can leave it checked; if you
uncheck it, an "on behalf of" note may show up on the recipient's side. For the
initial setup, leaving it checked gives the cleanest result.</li>
The next screen asks for the SMTP details:</li>
</ul>
SMTP Server : smtp.gmail.com</span></span>
Port        : 465  (SSL)   or   587 (TLS)</span></span>
Username    : erdincyasan@gmail.com   (the full Gmail address, not just "erdincyasan")</span></span>
Password    : the 16-digit app password you generated (no spaces, one continuous string)</span></span></code></pre>

Once you save, Google sends a verification code to iam@erdincyasan.com</code>.
Thanks to Step 1, that mail lands in your Gmail. Click the link in the code or
enter the code.</li>
</ul>
When it's done, you can pick iam@erdincyasan.com</code> from the "From" field while
composing a new mail in Gmail. Inbound is in Gmail, outbound is in Gmail. You
didn't pay a cent.</p>
Where you get stuck: 535-5.7.8 Username and Password not accepted</code></h2>
When saving the SMTP settings in Step 3, this is the error you hit most often.
The reasons, in order:</p>

You entered your normal Gmail password.</strong> You need to use the app password.</li>
2FA is off.</strong> Since you can't generate an app password, you're already
entering something wrong.</li>
The username is incomplete.</strong> Not erdincyasan</code>, but the full address:
erdincyasan@gmail.com</code>.</li>
You didn't remove the spaces from the app password.</strong> Google shows the code
with spaces like abcd efgh ijkl mnop</code>; you need to enter it into SMTP as one
continuous string (abcdefghijklmnop</code>).</li>
An invisible character slipped in while copying.</strong> Enter the app password by
hand, carefully.</li>
</ul>
Limits (to be honest)</h2>
This setup is free and gets the job done, but it's not magic:</p>

It's not a real mailbox. Nothing is stored on the Cloudflare side, it just
forwards. If you delete it in Gmail, that mail is gone.</li>
Outbound mail technically leaves from Gmail's server. That's why SPF/DKIM
alignment doesn't fully</strong> line up with your domain; traces of Gmail remain in
the header. It's not a problem for personal/small use, but it's not enough for
someone looking for a corporate mail infrastructure.</li>
If you have serious sending volume or delivery guarantees matter, a separate
mail provider (like Zoho, Google Workspace) or a transactional SMTP service is
the better choice.</li>
</ul>
But if you're saying "I just want a professional-looking address from my domain
without paying", this duo is exactly for that.</p>


Local Ignore Rules in Git: .git/info/exclude and core.excludesFile
2026-08-10T00:00:00+00:00
Intro</h2>
I was working on a big project together with a team. Not everyone on the
project used Claude. While pairing, I kept dropping things into the project
root. I would scan a topic and get docs as .md output, throw in temporary json
files, add images. None of these had anything directly to do with the project.</p>
There were two things I did not want. First, adding these files to .gitignore,
because .gitignore gets committed and goes to everyone as an unrelated change.
Second, having them show up in the file changes; I did not want to pollute the
diff with my own local work.</p>
So I needed an ignore solution that touched the repo not at all and only applied
on my own machine. I looked, and I found it: .git/info/exclude.</p>
Three places, three purposes</h2>
In Git there are three places you can write an ignore rule, and each serves a
different purpose:</p>

.gitignore</code>: rules shared with the repo, committed, binding on everyone.</li>
.git/info/exclude</code>: only for your machine and your clone. Not committed,
pushed, or cloned; nobody on the team sees it.</li>
core.excludesFile</code>: a file you point to via git config. Can be global (for
all your repos, per-user) or local to a single repo.</li>
</ul>
What I needed was the second one, but knowing all three is useful.</p>
.git/info/exclude, personal and never enters the repo</h2>
This was exactly what I was looking for. The rules stay only with me and touch
the repo not at all. The file already exists in every repo, you do not need to
create anything extra, just appending lines is enough:</p>
echo</span> "</span>*.local</span>"</span> >></span> .git/info/exclude</span></span>
echo</span> "</span>scratch/</span>"</span> >></span> .git/info/exclude</span></span></code></pre>
I tested this locally. After writing the *.local</code> rule, the untracked
note.local</code> file was ignored:</p>
git</span> check-ignore</span> -</span>v</span> note.local</span></span>
#</span> .git/info/exclude:1:*.local	note.local</span></span></code></pre>
The best part is that this file is not cloned and not pushed. So I kept the docs
and json files I dropped into the project root here, and they did not show up in
anyone's diff.</p>
Important pitfall: a file that is already tracked</h2>
This is very commonly misunderstood, so I am writing it separately. If a file is
already committed (tracked), adding it to exclude changes nothing. Git does not
apply ignore rules to tracked files.</p>
I tested it: I added a tracked file to exclude, and git check-ignore -v</code>
returned nothing. Because a tracked file is not considered "ignored".</p>
The fix is to first drop the file from the index. The file in your working
directory is not deleted, only git's tracking ends:</p>
git</span> rm</span> -</span>-cached</span> tracked.txt</span></span>
#</span> the file stays on disk, git just no longer tracks it</span></span>
#</span> after this the .gitignore or exclude rule kicks in</span></span></code></pre>core.excludesFile, a global personal ignore</h2>
Then there are things you do not want to write over and over in every repo.
Like .DS_Store</code>, .idea/</code>, *.swp</code>. Instead of writing these separately in
every project, you can define them centrally once:</p>
git</span> config</span> -</span>-global</span> core.excludesFile</span> ~/.gitignore_global</span></span>
echo</span> "</span>*.conf</span>"</span> >></span> ~/.gitignore_global</span></span></code></pre>
I tried it locally, and the *.conf</code> rule ignored app.conf</code>:</p>
git</span> check-ignore</span> -</span>v</span> app.conf</span></span>
#</span> ~/.gitignore_global:1:*.conf	app.conf</span></span></code></pre>
Global is not required; without --global</code>, you can also use it for a single
repo with git config core.excludesFile <path></code>.</p>
Precedence order</h2>
Now we get to the part that really causes confusion. If there is a rule in more
than one place for the same file, who wins? I tested it locally; from highest to
lowest the order is:</p>

Command-line patterns (like git ls-files)</li>
.gitignore</code> files (a rule in a deeper directory overrides the one above, and
within the same file the last matching rule wins)</li>
.git/info/exclude</code></li>
core.excludesFile</code></li>
</ol>
I confirmed this with two negation tests. When I wrote !note.local</code> into
.gitignore</code>, it overrode the *.local</code> rule in exclude and the file was not
ignored. So .gitignore</code> has priority over exclude. Then when I wrote !build/</code>
into exclude, it overrode the build/</code> rule in core.excludesFile. So exclude
also has priority over core.excludesFile.</p>
In short, the shared rule (.gitignore</code>) always overrides your personal rules.
That is worth keeping in mind.</p>
Debugging: why is a file ignored?</h2>
When you wonder why a file is ignored (or not ignored), a single command is
enough:</p>
git</span> check-ignore</span> -</span>v</span> <</span>fil</span>e</span>></span></span></code></pre>
The -v</code> flag shows which file, which line, and which rule matched:</p>
git</span> check-ignore</span> -</span>v</span> note.local</span></span>
#</span> .git/info/exclude:1:*.local	note.local</span></span></code></pre>
If no output comes, there are two possibilities: either the file is not ignored,
or it is already tracked (tracked files are not reported by this command).</p>
From the team's perspective: exclude or a shared rule?</h2>
In my case the answer was clear. The files I dropped were entirely personal, the
team did not care about them, so .git/info/exclude</code> was the right choice. I kept
my own mess on my own machine without touching the repo.</p>
I have a simple distinction in mind:</p>

Things specific only to you (IDE settings, personal scratch, pairing
leftovers): .git/info/exclude</code> or global core.excludesFile</code>. Does not
pollute the repo.</li>
Things that should be excluded by the whole team (node_modules/</code>, build
output): a committed .gitignore</code>. Because exclude is not shared, and everyone
needs to see the same behavior.</li>
</ul>
Conclusion</h2>
In short, .gitignore is not the only place. For personal work there are
.git/info/exclude</code> and core.excludesFile</code>, and these touch the repo not at
all. The next time you drop a temporary file into the project root and think
"how do I hide this", this is the solution.</p>


PostgreSQL LIKE Performance: CAST, Concat, and OR Comparison
2026-06-29T00:00:00+00:00
I started thinking about a query I came across recently. There were two columns: LongColumn</code> (bigint</code>) and Description</code> (text</code>). The search worked like this:</p>
//</span> Old code: CAST + concat</span></span>
context</span>.</span>Documents</span></span>
    .</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span></span>
        d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span> +</span> "</span> "</span> +</span> d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span></code></pre>
EF Core sent this to PostgreSQL as LongColumn::text || ' ' || Description</code>. To run a LIKE search on a bigint</code> column, you needed to cast with ::text</code> and concatenate it with Description. Later, the data in LongColumn</code> was moved to a new text</code> column called TextColumn</code>. The CAST was no longer needed.</p>
So how should we write the query now? Six different approaches:</p>
//</span> A: CAST + concat (old way)</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span></span>
    d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span> +</span> "</span> "</span> +</span> d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> B: CAST, single column</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> C: TextColumn concat</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span></span>
    d</span>.</span>TextColumn</span> +</span> "</span> "</span> +</span> d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> D: TextColumn single column</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>TextColumn</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> E: TextColumn OR Description (separate LIKE)</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>TextColumn</span>,</span> pattern</span>)</span></span>
         ||</span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span>
</span>
//</span> F: LongColumn::text OR Description (CAST OR)</span></span>
.</span>Where</span>(</span>d</span> =></span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>LongColumn</span>.</span>ToString</span>(</span>)</span>,</span> pattern</span>)</span></span>
         ||</span> EF</span>.</span>Functions</span>.</span>Like</span>(</span>d</span>.</span>Description</span>,</span> pattern</span>)</span>)</span></span></code></pre>
Which one is faster? How expensive is CAST? Does concat break index usage? Can the OR approach use an index? To answer these questions, I set up a benchmark with 2 million rows.</p>
Benchmark Setup</h2>

PostgreSQL 16 (Docker), port 5433</li>
documents</code> table: Id</code>, LongColumn (bigint)</code>, TextColumn (text)</code>, Description (text)</code> - 2 million rows</li>
TextColumn</code>: string representation of LongColumn</code> + Turkish text. Average 439 bytes</li>
LongColumn</code>: random 10-digit bigint. String representation averages 14 bytes</li>
Description</code>: Turkish text, average 423 bytes</li>
Indexes on TextColumn</code> and Description</code> (you cannot create a text index on a bigint</code> column)</li>
3 index strategies: None, B-tree, GIN trigram (pg_trgm</code>)</li>
3 patterns: %ankara%</code> (%42 rows), %de%</code> (</del>%99 rows), %xyzqwerty%</code> (none)</li>
Each scenario run 5 times, best/worst discarded, average of 3</li>
Measured with EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)</code></li>
</ul>
SQL Generated by EF Core</h2>
A - CAST + concat</strong></p>
--</span> @__pattern_1='%ankara%'</span></span>
SELECT</span> d.</span>"</span>Id</span>"</span>, d.</span>"</span>Description</span>"</span>, d.</span>"</span>LongColumn</span>"</span>, d.</span>"</span>TextColumn</span>"</span></span>
FROM</span> documents </span>AS</span> d</span></span>
WHERE</span> d.</span>"</span>LongColumn</span>"</span>::</span>text</span> ||</span> '</span> '</span> ||</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
B - CAST, single column</strong></p>
WHERE</span> d.</span>"</span>LongColumn</span>"</span>::</span>text</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
C - TextColumn concat</strong></p>
WHERE</span> d.</span>"</span>TextColumn</span>"</span> ||</span> '</span> '</span> ||</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
D - TextColumn single column</strong></p>
WHERE</span> d.</span>"</span>TextColumn</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
E - TextColumn OR Description</strong></p>
WHERE</span> d.</span>"</span>TextColumn</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span> OR</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
F - LongColumn::text OR Description</strong></p>
WHERE</span> d.</span>"</span>LongColumn</span>"</span>::</span>text</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span> OR</span> d.</span>"</span>Description</span>"</span> LIKE</span> @__pattern_1</span> ESCAPE </span>'</span>'</span></span></code></pre>
d.LongColumn.ToString()</code> becomes LongColumn::text</code>. string + string</code> becomes ||</code>. ESCAPE ''</code> is EF Core's default, no performance impact.</p>
Results - With GIN Trigram Index</h2>
The most critical scenario is with a GIN index. I skip B-tree since it gives the same result as None - LIKE '%x%'</code> is fundamentally incompatible with B-tree.</p>
Approach</th> Pattern</th> Time (ms)</th> Read Blocks</th> Rows</th></tr></thead>

A: CAST+concat</td> %ankara%</td> 702.35</td> 465,400</td> 1,036,239</td></tr>
A: CAST+concat</td> %de%</td> 645.73</td> 232,304</td> 1,991,384</td></tr>
A: CAST+concat</td> %xyzqwerty%</td> 468.41</td> 464,416</td> 0</td></tr>
B: CAST single</td> %ankara%</td> 131.93</td> 459,568</td> 0</td></tr>
B: CAST single</td> %de%</td> 328.45</td> 229,556</td> 0</td></tr>
B: CAST single</td> %xyzqwerty%</td> 137.11</td> 457,680</td> 0</td></tr>
C: TextConcat</td> %ankara%</td> 996.65</td> 453,224</td> 1,729,401</td></tr>
C: TextConcat</td> %de%</td> 640.01</td> 226,244</td> 1,999,945</td></tr>
C: TextConcat</td> %xyzqwerty%</td> 780.89</td> 451,480</td> 0</td></tr>
D: TextSingle</td> %ankara%</td> 1,644.34</td> 224,260</td> 850,373</td></tr>
D: TextSingle</td> %de%</td> 552.69</td> 224,148</td> 1,987,804</td></tr>
D: TextSingle</strong></td> %xyzqwerty%</strong></td> 0.01</strong></td> 0</strong></td> 0</td></tr>
E: TextOR</td> %ankara%</td> 2,480.59</td> 223,484</td> 1,297,051</td></tr>
E: TextOR</td> %de%</td> 543.10</td> 223,204</td> 1,999,945</td></tr>
E: TextOR</strong></td> %xyzqwerty%</strong></td> 0.01</strong></td> 0</strong></td> 0</td></tr>
F: CAST OR</td> %ankara%</td> 1,776.36</td> 222,064</td> 777,179</td></tr>
F: CAST OR</td> %de%</td> 627.46</td> 221,848</td> 1,991,384</td></tr>
F: CAST OR</td> %xyzqwerty%</td> 459.11</td> 443,016</td> 0</td></tr>
</tbody></table>
Key Finding 1: GIN Index - Who Uses It, Who Can't?</h2>
Focus on the %xyzqwerty%</code> pattern. This pattern exists in zero rows - it shows the index's real effect most clearly:</p>
#</th> Approach</th> SQL Summary</th> Time</th> Scan Type</th> Index?</th></tr></thead>

A</td> CAST+concat</td> LongCol::text || Desc</code></td> 468ms</td> Seq Scan</td> ❌</td></tr>
B</td> CAST single</td> LongCol::text</code></td> 137ms</td> Seq Scan</td> ❌</td></tr>
C</td> TextConcat</td> TextCol || Desc</code></td> 781ms</td> Seq Scan</td> ❌</td></tr>
D</strong></td> TextSingle</strong></td> TextCol</code></td> 0.01ms</strong></td> Bitmap Index Scan</strong></td> ✅</td></tr>
E</strong></td> Text OR</strong></td> TextCol OR Desc</code></td> 0.01ms</strong></td> BitmapOr</strong></td> ✅✅</td></tr>
F</td> CAST OR</td> LongCol::text OR Desc</code></td> 459ms</td> Seq Scan</td> ❌</td></tr>
</tbody></table>
Only D and E can use the GIN index. Why?</p>
A, B, C:</strong> ||</code> concat and ::text</code> CAST are expressions</em>. The GIN index is on the TextColumn</code> and Description</code> columns. Expressions don't match these indexes - the planner falls back to Seq Scan.</p>
D:</strong> TextColumn</code> is a direct column reference. ix_text_gin</code> is exactly on this column. The planner immediately uses Bitmap Index Scan.</p>
E:</strong> Two direct column references connected by OR. PostgreSQL scans ix_text_gin</code> and ix_desc_gin</code> separately, then combines results with BitmapOr</strong>. Two indexes, one pass.</p>
F:</strong> LongColumn::text</code> is CAST, Description</code> is direct. The CAST part cannot use an index. PostgreSQL drops the entire</em> OR expression to Seq Scan - even though Description has a GIN index.</p>
Key Finding 2: E's EXPLAIN Plan - BitmapOr</h2>
Approach E (TextColumn OR Description</code>) with GIN index produces this plan:</p>
Bitmap Heap Scan (time=0.003ms, rows=0)</span></span>
  -> BitmapOr</span></span>
    -> Bitmap Index Scan on ix_text_gin (time=0.003ms)</span></span>
       Index Cond: ("TextColumn" ~~ '%xyzqwerty%')</span></span>
    -> Bitmap Index Scan on ix_desc_gin (time=0.003ms)</span></span>
       Index Cond: ("Description" ~~ '%xyzqwerty%')</span></span></code></pre>
Two indexes scanned in parallel, combined with BitmapOr, heap never touched. Result: 0.01ms.</p>
This shows why separate LIKE + OR is so much better than concat. Concat (A, C) turns the expression into a single expression and disables the index, while OR lets each column use its index independently.</p>
Key Finding 3: CAST Poisons OR</h2>
F (LongColumn::text OR Description</code>) does a Seq Scan even with a GIN index:</p>
Gather (workers=2) -> Parallel Seq Scan</span></span>
  Filter: ((LongColumn::text ~~ '%xyzqwerty%') OR (Description ~~ '%xyzqwerty%'))</span></span>
  Rows Removed by Filter: 666,667 (x3 workers = 2M)</span></span>
  Execution Time: 459ms</span></span></code></pre>
Description has a GIN index (ix_desc_gin</code>). But because LongColumn::text</code> CAST is non-indexable, PostgreSQL plans the entire OR expression as a Seq Scan. A single non-indexable term leaves the whole query without index benefits.</p>
This shows why the migration was critical: as long as LongColumn</code> (bigint) remains, whether you use concat or OR, you get no index benefit.</p>
Key Finding 4: Speed Ranking (GIN, sparse pattern)</h2>
Winners:</p>

D and E: 0.01ms</strong> - uses index, sub-millisecond</li>
B: 137ms</strong> - Seq Scan but shortest data (14 bytes)</li>
A: 468ms</strong> - Seq Scan, CAST + concat (~438 bytes)</li>
F: 459ms</strong> - Seq Scan, CAST OR (~438 bytes)</li>
C: 781ms</strong> - Seq Scan, TextConcat (~863 bytes)</li>
</ol>
C is slowest because it scans the largest data (TextColumn 439B + Description 423B = 862B). B is the fastest Seq Scan because it scans only 14 bytes of LongColumn::text.</p>
But when the index is in play, data size no longer matters - D scans 439 bytes but still takes 0.01ms thanks to the index.</p>
Other Findings</h2>
Index is not used for frequent patterns.</strong> For %de%</code> and %ankara%</code>, all approaches use Seq Scan. The planner knows that when many rows match, heap lookup cost exceeds a direct scan.</p>
CAST cost is low.</strong> The bigint::text</code> conversion is microsecond-level. The real cost is concatenating two large columns.</p>
A is faster than C.</strong> CAST+concat (468ms) is faster than TextConcat (781ms). Reason: LongColumn::text</code> is 14 bytes, TextColumn</code> is 439 bytes. Data size is the deciding factor, not CAST cost.</p>
Practical Recommendations</h2>


Never use concat in a LIKE query.</strong> The col1 || ' ' || col2</code> expression completely disables column-level indexes. Always use separate LIKE + OR</strong> instead.</p>
</li>

When using OR, don't include CAST columns.</strong> Even a single CAST term makes the entire OR fall to Seq Scan. Consider writing the CAST column as a separate WHERE condition and combining with UNION</code>.</p>
</li>

Migrate non-text columns to text.</strong> If you need LIKE search on types like bigint</code>, migrate to a text column. CAST disappears and GIN index becomes usable.</p>
</li>

GIN trigram index is devastating for sparse patterns.</strong> But the planner won't use it for frequent patterns. Evaluate the INSERT/UPDATE cost of the index.</p>
</li>

Separate LIKE + OR is as fast as single-column LIKE.</strong> Both E (TextColumn OR Description</code>) and D (TextColumn</code>) take 0.01ms. Adding the second column has negligible index cost (BitmapOr).</p>
</li>

Measure on your own data.</strong> This benchmark is 2M rows, Docker macOS. Test with EXPLAIN ANALYZE</code> in your own environment.</p>
</li>
</ol>
Sources</h2>

GitHub - pg-perf benchmark project</a></li>
PostgreSQL pg_trgm documentation</a></li>
Npgsql EF Core - string translations</a></li>
</ul>


.NET Memory Management 1: Stack, Heap and Strings
2026-06-28T00:00:00+00:00
Hey there. This week I decided to focus on memory management after a recent
interview. I had surface-level knowledge on the topic and wanted to go deeper.
What is the stack, what is the heap, why does string live on the heap, what
happens behind the scenes when CLR creates an object, how does Span<T></code> work
without allocating memory, when does GC kick in, who benefits from
IDisposable</code> - I'll cover all of it in order.</p>
But first, let's start from the basics. What exactly are "stack and heap"?</p>
Finding Space for Data</h2>
When you define a variable:</p>
int</span> x</span> =</span> 5</span>;</span></span>
string</span> name</span> =</span> "</span>Erdinc</span>"</span>;</span></span>
User</span> user</span> =</span> new</span> User</span> {</span> Name</span> =</span> "</span>Erdinc</span>"</span>,</span> Age</span> =</span> 30</span> }</span>;</span></span></code></pre>
Where do x</code>, name</code>, and user</code> live? In your computer's RAM - okay.
But where in RAM? In some corner, the middle? Answer: it depends on the type.</strong></p>
The .NET runtime uses two main regions for memory management:</p>
Region</th> Description</th></tr></thead>

Stack</strong></td> A LIFO (Last-In-First-Out) structure where method calls, local variables, and parameters live. Small, fast, automatically cleaned.</td></tr>
Heap</strong></td> The region where dynamically allocated, long-lived objects live. Large, managed by the GC.</td></tr>
</tbody></table>
Understanding the difference between the two is the first step in grasping the
performance of the code you write.</p>
Stack: LIFO Structure</h2>
The best analogy for understanding how the stack works is a stack of plates.</strong>
When you want to add a plate, you put it on top. When you want to take one,
you take the top one. You can't pull one from the middle. The last plate you
put on is the first one taken. That's LIFO.</p>
[Plate 3]  ← Last placed, first taken (Last-In)</span></span>
[Plate 2]</span></span>
[Plate 1]  ← First placed, last taken (First-Out)</span></span></code></pre>
This is exactly what happens on the stack. Methods run stacked on top of each
other, and when a method finishes, its variables are cleaned up immediately:</p>
/*</span></span>
 * When Calculate finishes, all its variables (a, b, result) are</span></span>
 * completely removed from memory. But what exactly is this "removal"?</span></span>
 *</span></span>
 * At the CPU level, the stack is managed by the RSP (Stack Pointer) register.</span></span>
 * When entering a method, RSP is pulled down (sub rsp, N), allocating</span></span>
 * N bytes of space. When the method returns, RSP is pushed up</span></span>
 * (add rsp, N), "freeing" that space.</span></span>
 *</span></span>
 * This is called "Stack Pointer Adjustment" or simply "stack unwinding."</span></span>
 *</span></span>
 * Key point: the data in the freed region is NOT physically DELETED.</span></span>
 * It is just marked as no longer "in use." The operating system can</span></span>
 * overwrite the same memory addresses with new values on the next</span></span>
 * method call. This is why the compiler gives an error if you try to</span></span>
 * read an uninitialized local variable in C# - the value you read</span></span>
 * could be leftover garbage from the previous method.</span></span>
 */</span></span>
void</span> Calculate</span>(</span>)</span></span>
{</span></span>
    int</span> a</span> =</span> 10</span>;</span>       //</span> a = 10 written to stack</span></span>
    int</span> b</span> =</span> 20</span>;</span>       //</span> b = 20 written to stack</span></span>
    int</span> result</span> =</span> Add</span>(</span>a</span>,</span> b</span>)</span>;</span>  //</span> Add method called</span></span>
}</span>   //</span> When Calculate returns, RSP is pushed up, frame is freed</span></span>
</span>
int</span> Add</span>(</span>int</span> x</span>,</span> int</span> y</span>)</span></span>
{</span></span>
    int</span> sum</span> =</span> x</span> +</span> y</span>;</span>  //</span> New frame for x, y, sum opened on stack</span></span>
    return</span> sum</span>;</span>       //</span> When Add returns, its own frame is freed</span></span>
}</span></span></code></pre>
The stack grows as methods are called and shrinks as methods return. Each
method creates its own stack frame.</strong> The frame contains the method's
parameters, local variables, and return address. Visually:</p>
flowchart TB
    subgraph T1["1. Calculate called"]
        direction LR
        A1["[Empty]"]
    end
    subgraph T2["2. int a = 10"]
        direction LR
        A2["a = 10"]
    end
    subgraph T3["3. int b = 20"]
        direction LR
        A3["b = 20"]
        A3b["a = 10"]
    end
    subgraph T4["4. Add(10, 20) called"]
        direction LR
        A4["sum = 30"]
        A4b["y = 20"]
        A4c["x = 10"]
        A4d["--- frame boundary ---"]
        A4e["b = 20"]
        A4f["a = 10"]
    end
    subgraph T5["5. Add returned (frame removed)"]
        direction LR
        A5["result = 30"]
        A5b["b = 20"]
        A5c["a = 10"]
    end
    subgraph T6["6. Calculate returned (all removed)"]
        direction LR
        A6["[Empty]"]
    end

    T1 --> T2 --> T3 --> T4 --> T5 --> T6
</pre>
Notice: when Add returns, x</code>, y</code>, sum</code> - along with the frame - were
immediately</strong> removed. We didn't wait for the GC to come. This is called
deterministic cleanup.</strong></p>
Garbage Values and Memory Safety</h2>
We said earlier: the data in the freed stack region is not physically deleted.
So what happens if we try to access this "unswept" data?</p>
The C++ Side: Here's an Address, Go Wherever You Want</h3>
C++ puts up no barriers. If you declare a variable on the stack, don't
initialize it, and try to read it:</p>
void</span> Foo</span>(</span>)</span></span>
{</span></span>
    int</span> previousData </span>=</span> 42</span>;</span>    //</span> left a value on the stack</span></span>
}</span></span>
</span>
void</span> Bar</span>(</span>)</span></span>
{</span></span>
    int</span> x</span>;</span>                    //</span> not initialized!</span></span>
    std</span>::</span>cout </span><<</span> x</span>;</span>           //</span> prints 42 or some other random number</span></span>
}</span></span></code></pre>
When Bar</code> is called, its stack frame might land exactly on the region
Foo</code> left behind. x</code>'s value will be 42</code> - but this is pure coincidence.
In another run you'll get a completely different number. This is called
undefined behavior.</strong> The compiler won't error, you won't crash at runtime;
you'll just get wrong results without ever knowing it.</p>
Even worse, C++ pointer arithmetic lets you step completely outside the stack
and access completely different data within the same process:</p>
int</span> arr</span>[</span>3</span>]</span> =</span> {</span>1</span>,</span> 2</span>,</span> 3</span>}</span>;</span></span>
int</span>*</span> p </span>=</span> arr</span>;</span></span>
p </span>+=</span> 100</span>;</span>                //</span> 100 elements past the array - undefined region</span></span>
std</span>::</span>cout </span><<</span> *</span>p</span>;</span>         //</span> reads whatever is there</span></span></code></pre>
On modern operating systems, thanks to virtual memory, you can't access
another program's</strong> memory - the MMU won't allow it, you'd get a segfault.
But within your own process, you can go to any address and read it.</p>
The C# Side: The Compiler Blocks You</h3>
C# is the polar opposite of C++ in this regard. C# memory operations are safe.</strong>
Let's try the same scenario in C#:</p>
void</span> Bar</span>(</span>)</span></span>
{</span></span>
    int</span> x</span>;</span></span>
    Console</span>.</span>WriteLine</span>(</span>x</span>)</span>;</span>  //</span> COMPILE ERROR: Use of unassigned local variable 'x'</span></span>
}</span></span></code></pre>
The C# compiler performs definite assignment</strong> analysis. It requires that
a local variable must always have a value assigned before it is read. If it
isn't assigned, you get an error at compile time - it never even reaches
runtime.</p>
The reason is exactly what you said: reading an uninitialized variable means
you get whatever happens to be in memory at that moment. There's a random
value there, and that value can break your program's logic.</p>
Consider a hospital software system:</p>
//</span> This code won't compile in C# - but let's assume it did</span></span>
int</span> insulinDose</span>;</span>                  //</span> not assigned!</span></span>
AdministerInsulin</span>(</span>patient</span>,</span> insulinDose</span>)</span>;</span>  //</span> applies a random dose</span></span></code></pre>
If insulinDose</code> reads the previous leftover value in memory (say, 999), the
patient could die. C# puts the "assign before use" rule precisely to prevent
this scenario. C++ offers no such protection - the error silently continues
running.</p>
You can use pointers in C#'s unsafe</code> context, but that's a deliberate choice
and requires the /unsafe</code> compiler flag. In normal C# code, you cannot
accidentally read an uninitialized value.</p>
Summary: Why Does C# Block It?</h3>
Situation</th> C++</th> C#</th></tr></thead>

Reading uninitialized local variable</td> Compiles, returns random value (undefined behavior)</td> Compile error (CS0165)</td></tr>
Going outside the stack with a pointer</td> Compiles, segfault or random data</td> Can't do it without unsafe</code></td></tr>
Array bounds overflow</td> Compiles, undefined behavior</td> Throws IndexOutOfRangeException</code></td></tr>
Using a null reference</td> Compiles, segfault</td> Throws NullReferenceException</code></td></tr>
</tbody></table>
The C# runtime performs extra checks to protect you. These checks have a
performance cost (like array bounds checking), but it's worth it for safety
and debugging convenience.</p>
Stack properties:</p>

Size:</strong> 1-8 MB per thread. Won't fill up unless you use stackalloc</code>.</li>
Speed:</strong> Allocation and deallocation is a single CPU instruction (stack pointer movement). Cache-friendly.</li>
Lifetime:</strong> Limited to method scope. When the method ends, the variable dies.</li>
What lives here:</strong> Value types like int</code>, bool</code>, double</code>, struct</code>, enum</code>. Also the references</strong> (addresses) of reference types.</li>
</ul>
The most critical rule of the stack: nothing whose size is unknown at
compile time can live on the stack.</strong> The stack frame size in a method call
must be calculated in advance.</p>
That's why:</p>
byte</span>[</span>]</span> buffer</span> =</span> new</span> byte</span>[</span>4096</span>]</span>;</span>  //</span> buffer reference (8 bytes) on stack, 4096 bytes on heap</span></span></code></pre>
The buffer</code> variable (an 8-byte address) is on the stack. But the 4096 bytes
it points to are on the heap. Because the lifetime of those 4096 bytes might
not end when the method finishes - someone else might still be using them.</p>
The Real Structure of an Array on the Heap</h3>
So how exactly does byte[4096]</code> sit on the heap? And when you write
buffer[150]</code>, how does CLR find the 150th byte? How does it know the
boundary? Let's break it down.</p>
The structure of an array object on the heap:</p>
flowchart LR
    subgraph Stack["Stack"]
        U["buffer = 0x00E100 (starting address of byte[] object on heap)"]
    end
    subgraph Heap["Heap"]
        direction TB
        subgraph Arr["byte[] object (address: 0x00E100)"]
            direction LR
            A1["MethodTable* (0x00A000) (8 bytes, address of Byte[] MethodTable)"]
            A2["Length = 4096 (4 bytes)"]
            A3["padding (4 bytes)"]
            A4["[0] = 0 (1 byte)"]
            A5["[1] = 0 (1 byte)"]
            A6["... (4094 bytes)"]
            A7["[4095] = 0 (1 byte)"]
        end
        subgraph MT["Byte[] MethodTable (0x00A000)"]
            direction LR
            M1["BaseSize: 16"]
            M2["ComponentSize: 1"]
            M3["ElementType: System.Byte"]
            M4["Rank: 1"]
            M5["IsArray: true"]
        end
    end
    U -.->|"holds the heap address"| Arr
    A1 -.->|"holds the MethodTable address"| MT
</pre>
MethodTable* (8 bytes): This is the heap address</strong> of the MethodTable
belonging to the Byte[]</code> type. It's a memory address like 0x00A000</code>.
CLR reads this address to learn what type the object is, the size of its
elements, its boundaries, and its behavior (methods). Each type has one
MethodTable, and all objects of that type share the same MethodTable.</p>
Notice: the buffer</code> variable on the stack holds the value 0x00E100</code>.
This value is the starting address of the byte[] object on the heap.</strong>
In other words, buffer</code> is the "address card" for that 4096-byte region on
the heap. When you hold this reference, CLR can do the following:</p>
1. Learn the type:</strong> buffer.GetType()</code> → first goes to the address
0x00E100 that buffer</code> holds, reads the 8-byte MethodTable* value (0x00A000)
there. 0x00A000 is the address of the Byte[] MethodTable. From that
MethodTable, it retrieves IsArray = true</code>, ElementType = System.Byte</code>,
Rank = 1</code>.</p>
2. Learn the length:</strong> buffer.Length</code> → reads the 4-byte Length</code> value
at offset 8 from 0x00E100. It's 4096.</p>
3. Access an element:</strong> When you write buffer[150]</code>, CLR takes three
controlled steps:</p>
1. Bounds check:    if (150 < 0 || 150 >= 4096) → throw IndexOutOfRangeException</span></span>
2. Address calc:    target = 0x00E100 + 16 (header) + (150 × 1) (componentSize)</span></span>
                    = 0x00E100 + 16 + 150</span></span>
                    = 0x00E196</span></span>
3. Read/Write:      *(byte*)0x00E196</span></span></code></pre>
The formula breakdown:</p>
Part</th> Value</th> Source</th></tr></thead>

Base address</strong></td> 0x00E100</code></td> buffer</code> reference on the stack</td></tr>
Header size</strong></td> 16 bytes</code> (8 MT + 4 Length + 4 padding)</td> BaseSize</code> in Array MethodTable</td></tr>
ComponentSize</strong></td> 1</code> (for byte)</td> ComponentSize</code> field in Array MethodTable</td></tr>
Length</strong></td> 4096</code></td> At offset 8 in the object</td></tr>
index</strong></td> 150</code></td> Your code</td></tr>
</tbody></table>
MethodTable has two more special fields for arrays:</p>

ComponentSize</code>:</strong> The size of each element in bytes. 1</code> for byte[]</code>,
4</code> for int[]</code>, the struct size for a struct array.</li>
BaseSize</code>:</strong> The size of the array's header (MT + Length + padding).
Actual object size = BaseSize + (Length × ComponentSize)</code>.</li>
</ul>
CLR extracts everything it needs for buffer[150]</code> from the MethodTable +
Length pair. It doesn't need a separate "start/length" struct because arrays
always start at index 0. start</code> is always 0.</p>
Start/Length in Span<T></h3>
What you described as "a struct type with start and length values" is actually
Span<T></code>. Span is a view struct that works on top of</strong> an array:</p>
byte</span>[</span>]</span> fullBuffer</span> =</span> new</span> byte</span>[</span>4096</span>]</span>;</span></span>
Span</span><</span>byte</span>></span> slice</span> =</span> fullBuffer</span>.</span>AsSpan</span>(</span>100</span>,</span> 50</span>)</span>;</span>  //</span> start at byte 100, take 50 bytes</span></span></code></pre>
Span itself is a struct (value type) living on the stack and contains:</p>
flowchart LR
    subgraph Stack["Stack"]
        direction TB
        subgraph Span["Span<byte> slice (stack)"]
            S1["_reference (8 bytes, holds heap address of element 100)"]
            S2["_length = 50 (4 bytes)"]
        end
    end
    subgraph Heap["Heap"]
        direction TB
        subgraph Arr["byte[] fullBuffer (0x00E100)"]
            direction LR
            MT["MethodTable* (8)"]
            LEN["Length = 4096 (4)"]
            PAD["padding (4)"]
            EL0["[0]...[99] (100 bytes, header + 0..99)"]
            EL100["[100] = slice start"]
            EL149["[149] = slice end"]
            EL150["[150]...[4095]"]
        end
    end
    S1 -.->|"skips the header, points directly to element 100"| EL100
</pre>
Span's _reference</code> field does not point to the start of the array, but to the
start of the slice</strong> (with the offset already added). When indexing on a
Span, CLR does:</p>
1. Slice bounds:     if (index < 0 || index >= 50) → error (Span's _length)</span></span>
2. Actual address:   target = _reference + (index × 1)</span></span></code></pre>
As you can see, Span carries the "start and length" information. But
byte[]</code> itself does not - an array always starts at 0, and its length is
embedded in the object. The start/length pair comes into play when a view is
needed.</p>
Where Does the Element Type Come From?</h3>
When reading buffer[150]</code>, CLR knows the 150th byte is a byte</code> from the
ComponentSize</strong> value. The Byte[]</code> MethodTable has ComponentSize = 1</code>.
For Int32[]</code> it's 4, for Double[]</code> it's 8.</p>
What if the element is a reference type? Consider string[]</code>:</p>
string</span>[</span>]</span> names</span> =</span> new</span> string</span>[</span>3</span>]</span>;</span></span></code></pre>
This array's structure on the heap:</p>
[MethodTable* → String[]]    (8 bytes)</span></span>
[Length = 3]                 (4 bytes)</span></span>
[padding]                    (4 bytes)</span></span>
[names[0] = null]            (8 bytes - string reference)</span></span>
[names[1] = null]            (8 bytes - string reference)</span></span>
[names[2] = null]            (8 bytes - string reference)</span></span>
Total: 16 + (3 × 8) = 40 bytes</span></span></code></pre>
Here, ComponentSize = 8</code> (reference size on 64-bit). Each element is a
reference; the string itself is elsewhere on the heap. The array only holds
addresses. When reading names[1]</code>:</p>
1. Address:   0x00E100 + 16 + (1 × 8) = 0x00E118</span></span>
2. Read:      *(string*)0x00E118 → 0x00F200 (address of the string)</span></span>
3. Go to string: read the string object at 0x00F200</span></span></code></pre>
GC also tracks these references. As long as the string[]</code> array itself is
alive, the strings pointed to by the array's references also stay alive (even
if nothing else references them).</p>
Heap and MethodTable</h2>
Think of the heap as a large plot of land.</strong> When you need space, you
allocate a parcel (allocation); when you're done, you clear it (GC collects).
Unlike the stack, there's no order here - each parcel is independent.</p>
But the real question is what CLR does behind the scenes when an object is
created on the heap. Let's step through what happens the moment you write
new User()</code>.</p>
What Happens When CLR Creates an Object?</h3>
var</span> user</span> =</span> new</span> User</span> {</span> Name</span> =</span> "</span>Erdinc</span>"</span>,</span> Age</span> =</span> 30</span> }</span>;</span></span></code></pre>
When this line executes, CLR follows these steps:</p>


Look up type info.</strong> Does CLR know the User</code> type? Where is the
MethodTable</code> for the User</code> class? (If it's the first use, the type is
loaded - type load.)</p>
</li>

Allocate memory.</strong> It looks at the BaseSize</code> field in the MethodTable</code>.
This field tells how many bytes an object of type User</code> will occupy on
the heap. That many bytes are allocated from the GC heap.</p>
</li>

Write the MethodTable pointer.</strong> The address of the MethodTable</code> is
written to the first 8 bytes (64-bit) or 4 bytes (32-bit) of the allocated
memory. This pointer (TypeHandle) is a critical reference that tells the
runtime which type the object belongs to.</p>
</li>

Zero out fields.</strong> The remaining space is zeroed. int</code> → 0, string</code> → null,
bool</code> → false.</p>
</li>

Call constructor.</strong> The User</code> constructor runs, writing the actual values
to the fields.</p>
</li>

Return the reference.</strong> The starting address</strong> of this heap-allocated
object is assigned to the var user</code> variable. This address is stored on
the stack.</p>
</li>
</ol>
Visually:</p>
flowchart LR
    subgraph Stack["Stack"]
        direction TB
        U["user = 0x001A3F (8 bytes)"]
    end

    subgraph Heap["Heap"]
        direction TB
        subgraph Obj["User object (address: 0x001A3F)"]
            direction LR
            MT["MethodTable* (8 bytes)"]
            F1["Age = 30 (4 bytes)"]
            PAD["padding (4 bytes)"]
            F2["Name = 0x00B210 (8 bytes)"]
        end
        subgraph MTBlock["User MethodTable"]
            direction LR
            MTInfo["BaseSize: 24
            EEClass*: 0xF0A100
            Parent MethodTable*: System.Object
            Interface count: 0
            Method slots: ..."]
        end
        subgraph Str["String 'Erdinc' (0x00B210)"]
            direction LR
            SM["MethodTable* (System.String)"]
            SL["Length = 6"]
            SC["chars: E r d i n c"]
        end
    end

    U -.->|"points to"| Obj
    MT -.->|"type info"| MTBlock
    F2 -.->|"Name points to"| Str
</pre>
What is MethodTable and What Does It Do?</h3>
Every type has a MethodTable.</strong> CLR creates this table when the type is
first loaded, and all objects of that type share the same MethodTable. Even
if you create a million User</code> objects, there is only one</strong> User</code>
MethodTable.</p>
MethodTable contents (simplified):</p>
Field</th> Description</th></tr></thead>

BaseSize</strong></td> How many bytes an object of this type occupies on the heap. The first field GC uses for allocation.</td></tr>
EEClass pointer</strong></td> Points to the EEClass</code> structure. Field offsets, interface list, property metadata live here.</td></tr>
Parent MethodTable</strong></td> The inheritance chain. If User</code>, its parent is System.Object</code>'s MethodTable.</td></tr>
Interface count and Interface map</strong></td> Which interfaces it implements. Used for casts and is</code> checks.</td></tr>
Method slots</strong></td> Addresses of virtual methods. Like ToString()</code>, GetHashCode()</code>.</td></tr>
</tbody></table>
So when you call user.GetType()</code>, CLR's only job is to read the MethodTable
pointer from the first 8 bytes of the object and return the corresponding
Type</code> object to you.</p>
Namespace and MethodTable Relationship</h3>
MethodTables are created per type</strong>, not per namespace. A namespace is a
logical grouping used at compile time. At runtime, there is no such thing as a
"namespace MethodTable."</p>
A type's full runtime identity consists of three parts:</p>
Assembly + Namespace + TypeName</span></span></code></pre>
For example:</p>
namespace</span> MyApp</span>.</span>Models</span></span>
{</span></span>
    public</span> class</span> User</span> {</span> ... </span>}</span>     //</span> Identity: MyApp.dll + MyApp.Models + User</span></span>
}</span></span>
</span>
namespace</span> MyApp</span>.</span>DTOs</span></span>
{</span></span>
    public</span> class</span> User</span> {</span> ... </span>}</span>     //</span> Identity: MyApp.dll + MyApp.DTOs + User</span></span>
}</span></span></code></pre>
These two User</code> classes have the same name but different namespaces.
Therefore, CLR creates two separate MethodTables</strong> for them. Each has its
own BaseSize</code>, field offsets, and method slots. Models.User</code> and
DTOs.User</code> are completely different types that just happen to share a name.</p>
Namespace information is not stored as a separate field inside the
MethodTable; it's held as part of the type's name.</strong> When you call
Type.FullName</code>, you get "MyApp.Models.User"</code>; this string comes from the
type's metadata. CLR uses this full name when loading a type:</p>
1. Does the assembly contain a type called "MyApp.Models.User"?</span></span>
2. If yes, load its MethodTable (or use it if already loaded)</span></span>
3. If not, throw TypeLoadException</span></span></code></pre>
So, the namespace is necessary for type resolution, but the MethodTable itself
is type-based, not namespace-based. 50 classes in the same namespace = 50
separate MethodTables.</p>
Accessing Properties: The Offset Mechanism</h3>
When you write user.Name</code>, how does CLR know which bytes in the heap object
belong to the Name</code> property? Answer: field offset.</strong></p>
The EEClass</code> holds an offset value for each field:</p>
User Class EEClass (simplified):</span></span>
  Field: Age      → offset: 8   (right after the MethodTable pointer)</span></span>
  Field: Name     → offset: 16  (Age 4 bytes + padding 4 bytes = 8 bytes later)</span></span>
  Total size      → 24 bytes    (8 MT + 4 Age + 4 pad + 8 Name)</span></span></code></pre>
Why is there padding? The CPU requires alignment</strong> for faster memory access.
On a 64-bit system, 8-byte references must be at addresses that are multiples
of 8. That's why 4 bytes of padding are inserted between Age</code> (4 bytes) and
Name</code> (8 bytes).</p>
CLR uses these offset values to translate the user.Name</code> call into:</p>
//</span> user.Name is actually this:</span></span>
string</span> name</span> =</span> *</span>(</span>string</span>*</span>)</span>(</span>(</span>byte</span>*</span>)</span>user</span> +</span> 16</span>)</span>;</span>  //</span> read the reference at byte 16 of the object</span></span></code></pre>
The advantage of offset access:</strong> There's no need to maintain a separate
property address map for each object. All User</code> objects use the same offsets.
Only the base address changes: object_address + Age_offset = Age's address</code>.</p>
Note: Since Age</code> is a value type, its value is inside</strong> the heap object.
But since Name</code> is a reference type, only its address</strong> is inside the heap
object. The actual string data is at a different heap address.</p>
Offset in Inheritance</h3>
class</span> Person</span></span>
{</span></span>
    public</span> int</span> Id</span> {</span> get</span>;</span> set</span>;</span> }</span></span>
}</span></span>
</span>
class</span> User</span> :</span> Person</span></span>
{</span></span>
    public</span> string</span> Name</span> {</span> get</span>;</span> set</span>;</span> }</span></span>
    public</span> int</span> Age</span> {</span> get</span>;</span> set</span>;</span> }</span></span>
}</span></span></code></pre>
The User</code> object on the heap:</p>
[MethodTable* → User]  (8 bytes, at the very start)</span></span>
[Id: int]              (offset 8, field inherited from Person)</span></span>
[Name: string ref]     (offset 16, 4 bytes Id + 4 padding = 8)</span></span>
[Age: int]             (offset 24)</span></span>
Total: 32 bytes</span></span></code></pre>
The critical point here: parent class fields always come before</strong> child
class fields. This way, even when you do Person person = user;</code>, person.Id</code>
is read from the same offset. Because the Person</code> MethodTable also knows
Id</code> is at byte 8 - and at byte 8 of the user</code> object, Id</code> really is there.</p>
Value Type vs Reference Type: Summary Table</h2>
Property</th> Value Type (struct</code>, int</code>, bool</code>)</th> Reference Type (class</code>, string</code>)</th></tr></thead>

Where it lives</strong></td> Where its owner lives (stack or inside heap)</td> Always on the heap</td></tr>
Assignment behavior</strong></td> Value is copied</td> Reference (address) is copied</td></tr>
Can be null?</strong></td> No (yes with int?</code> nullable wrapper)</td> Yes</td></tr>
Default value</strong></td> Zeroed state (0</code>, false</code>, default</code>)</td> null</code></td></tr>
Inheritance</strong></td> From System.ValueType</code>, sealed</td> From Object</code></td></tr>
GC impact</strong></td> Goes away automatically when owner is collected</td> Requires GC collection</td></tr>
How it sits in an object</strong></td> Value is inside the object</td> Address is inside the object</td></tr>
</tbody></table>
The String Matter</h2>
String has a special place in this story. It's the type that confuses people
the most.</p>
string</span> a</span> =</span> "</span>hello</span>"</span>;</span></span>
string</span> b</span> =</span> a</span>;</span></span>
b</span> =</span> "</span>world</span>"</span>;</span></span>
//</span> a is still "hello", right? Yes.</span></span></code></pre>
String is a reference type - it lives on the heap. But it's immutable.</strong>
That's why the b = "world"</code> assignment above doesn't affect a</code> - it doesn't
change the content of the string b</code> points to; it assigns the address of a
new string to b</code>.</p>
In fact, the heap structure of a string also starts with a MethodTable:</p>
String object (heap):</span></span>
  [MethodTable* → System.String]  (8 bytes)</span></span>
  [Length: int = 5]               (4 bytes)</span></span>
  [Padding]                       (4 bytes)</span></span>
  [First Char: 'h']               (2 bytes)</span></span>
  [Second Char: 'e']              (2 bytes)</span></span>
  ...</span></span></code></pre>
Length</code> and characters are inside the object, accessible at fixed offsets.
But you cannot change the content</strong> because CLR doesn't know the string is
writable - the object is marked as readonly.</p>
Why Immutable?</h3>

Thread safety.</strong> Multiple threads can read the same string without fear.</li>
Interning.</strong> Strings with the same content are stored once in memory.</li>
Security.</strong> Just because you passed a string as a parameter doesn't mean
the method can modify it.</li>
</ol>
But this immutability comes at a cost:</p>
string</span> result</span> =</span> "</span>"</span>;</span></span>
for</span> (</span>int</span> i</span> =</span> 0</span>;</span> i</span> <</span> 10000</span>;</span> i</span>++</span>)</span></span>
{</span></span>
    result</span> +=</span> "</span>x</span>"</span>;</span>   //</span> New string object every loop. 10,000 allocations.</span></span>
}</span></span></code></pre>
This code creates 10,000 new string</code> objects, polluting the heap. The right
way:</p>
var</span> sb</span> =</span> new</span> StringBuilder</span>(</span>)</span>;</span></span>
for</span> (</span>int</span> i</span> =</span> 0</span>;</span> i</span> <</span> 10000</span>;</span> i</span>++</span>)</span></span>
{</span></span>
    sb</span>.</span>Append</span>(</span>"</span>x</span>"</span>)</span>;</span></span>
}</span></span>
string</span> result</span> =</span> sb</span>.</span>ToString</span>(</span>)</span>;</span>  //</span> Single allocation.</span></span></code></pre>
Even though string is a reference type, it behaves like a value type. The ==</code>
operator compares content (not address). Copying is safe because it's
immutable. But in memory, it's always on the heap</strong> - it can't live on the
stack because its size is unknown at compile time and its lifetime can exceed
method scope.</p>
String Interning</h3>
CLR keeps frequently used strings in a pool called the intern pool:</strong></p>
string</span> a</span> =</span> "</span>dotnet</span>"</span>;</span></span>
string</span> b</span> =</span> "</span>dotnet</span>"</span>;</span></span>
Console</span>.</span>WriteLine</span>(</span>Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> b</span>)</span>)</span>;</span> //</span> True - same object.</span></span></code></pre>
Strings that are constant at compile time are automatically interned. You can
also do it manually at runtime:</p>
string</span> c</span> =</span> new</span> string</span>(</span>new</span> char</span>[</span>]</span> {</span> '</span>d</span>'</span>,</span> '</span>o</span>'</span>,</span> '</span>t</span>'</span>,</span> '</span>n</span>'</span>,</span> '</span>e</span>'</span>,</span> '</span>t</span>'</span> }</span>)</span>;</span></span>
string</span> d</span> =</span> string</span>.</span>Intern</span>(</span>c</span>)</span>;</span></span></code></pre>
So when a method returns a string at runtime, does interning happen
automatically? Two scenarios:</p>
Scenario A: Method returns a compile-time literal - interned.</strong></p>
string</span> GetHelloWorld</span>(</span>)</span></span>
{</span></span>
    return</span> "</span>Merhaba dunya</span>"</span>;</span>   //</span> compile-time literal</span></span>
}</span></span>
</span>
string</span> a</span> =</span> "</span>Merhaba dunya</span>"</span>;</span></span>
string</span> b</span> =</span> GetHelloWorld</span>(</span>)</span>;</span></span>
</span>
Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> b</span>)</span>;</span> //</span> True - both are the same intern object</span></span></code></pre>
The "Merhaba dunya"</code> literal in GetHelloWorld()</code>'s body is embedded in the
assembly metadata. When CLR loads the assembly, it also adds it to the intern
pool. When the method is called, it returns the same object from the pool. If
two literals are concatenated with +</code> and the compiler can optimize them into
a single literal at build time, the result is still interned.</p>
Scenario B: Method creates the string at runtime - not interned.</strong></p>
string</span> GetHelloWorld</span>(</span>)</span></span>
{</span></span>
    var</span> merhaba</span> =</span> "</span>Merhaba </span>"</span>;</span></span>
    var</span> dunya</span> =</span> "</span>dunya</span>"</span>;</span></span>
    return</span> merhaba</span> +</span> dunya</span>;</span>   //</span> runtime concat, new object</span></span>
}</span></span>
</span>
string</span> a</span> =</span> "</span>Merhaba dunya</span>"</span>;</span></span>
string</span> b</span> =</span> GetHelloWorld</span>(</span>)</span>;</span></span>
</span>
Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> b</span>)</span>;</span> //</span> False - b was created at runtime, not in the intern pool</span></span>
</span>
string</span> c</span> =</span> string</span>.</span>Intern</span>(</span>b</span>)</span>;</span>  //</span> Manual intern</span></span>
Object</span>.</span>ReferenceEquals</span>(</span>a</span>,</span> c</span>)</span>;</span> //</span> True - now it's the same pool object</span></span></code></pre>
Concatenation with +</code> using variables, StringBuilder.ToString()</code>,
Substring()</code>, ToUpper()</code>, reading from a file, JSON deserialization - all
of these create new heap objects at runtime. Even if the content is the same,
it doesn't automatically enter the intern pool. You need to call
string.Intern()</code>.</p>
In short, the issue is not the string's content</strong>, but how it was
created.</strong> We'll look into this more later.</p>
Interning prevents the same string from occupying heap space multiple times.
But excessive use can bloat GC's Gen 2 - because interned strings are
never</strong> collected by the GC (they live until the AppDomain shuts down).</p>
Summary: Stack, Heap, MethodTable Relationship</h2>
The complete journey of a new User()</code> call from start to finish:</p>
1. CLR looks at the User MethodTable → BaseSize: 24 bytes</span></span>
2. Allocates 24 bytes from the GC heap</span></span>
3. Writes the User MethodTable address to the first 8 bytes of allocated space</span></span>
4. Zeroes the remaining space, calls the constructor</span></span>
5. Assigns the heap address to the user variable on the stack</span></span>
6. user.Name call: reads the string address at offset 16 from the user address</span></span></code></pre>
When you understand this mechanism, you start understanding most performance
problems too. Every new</code> is an allocation. GC has an allocation budget</strong>
in its Gen 0 region; creating a new object consumes this budget. When the
budget hits zero, GC is triggered and collects unused objects. So every
allocation brings you one step closer to the next GC cycle. Every unnecessary
allocation is a preventable cost.</p>
What's Next</h2>
We've covered what stack and heap are, what CLR does when creating objects,
the role of MethodTable, and why string is special. But the real question is:</p>

"How do we avoid heap allocations when working with strings?"</p>
</blockquote>
The answer: Span<T></code>, Memory<T></code>, stackalloc</code>, and the IDisposable</code>
pattern. In the next part of this series, I'll cover these with code examples.
We'll also look at GC's generation mechanism, why finalizers are dangerous,
and how to catch memory leaks.</p>
References</h2>

Microsoft Docs - Memory management and garbage collection</a></li>
Stephen Toub - All About Span: Exploring .NET Memory</a></li>
.NET Runtime - MethodTable source</a></li>
.NET Runtime - Object layout</a></li>
Eric Lippert - The Stack Is An Implementation Detail</a></li>
</ul>

Erdinç Yaşan

Storing credentials in the repo: SOPS + age

Free Custom Domain Email with Cloudflare and Gmail

Local Ignore Rules in Git: .git/info/exclude and core.excludesFile

Conclusion</h2> In short, .gitignore is not the only place. For personal work there are .git/info/exclude</code> and core.excludesFile</code>, and these touch the repo not at all. The next time you drop a temporary file into the project root and think "how do I hide this", this is the solution.</p>

PostgreSQL LIKE Performance: CAST, Concat, and OR Comparison

.NET Memory Management 1: Stack, Heap and Strings