DEV Community: cynthia wahome

The Supabase Gotchas Nobody Warns You About (Until You Hit Them)

cynthia wahome — Fri, 20 Mar 2026 17:23:24 +0000

Supabase has some of the best developer experience (DX) in the BaaS space right now. DX is shorthand for how pleasant a tool is to work with — the docs, the dashboard, the auto-generated APIs, the speed at which you go from zero to something working. On all of those: Supabase is excellent.

But excellent DX has a shadow side. When a platform abstracts things this smoothly, it's easy to forget what's running underneath. And what's running underneath Supabase is PostgreSQL — a powerful, strict, battle-tested database that has its own permission system, its own rules, and absolutely no obligation to care how clean your dashboard looks.

These are the two things that will catch you — usually at the same time, usually showing the same symptom.

The Symptom

You've set up auth. Users sign up, verify their email, try to log in — and your app shows something like a "pending approval" or "no role assigned" screen even though everything completed correctly.

Your trigger is firing. Your RLS policies are in place. The Supabase dashboard looks fine.

Nothing is broken. Nothing is obviously wrong.

This is the trap.

Gotcha 1: The GRANT That Nobody Told You About

This is the most common question in the Supabase Discord and it's easy to see why — it violates every reasonable expectation.

When you enable Row Level Security (RLS) on a table in Supabase, you create policies that define who can do what with the rows. A policy might say: "authenticated users can read their own rows." Logical. Clear.

What the dashboard doesn't shout at you is that RLS policies and table permissions are two entirely separate systems in PostgreSQL.

Here's the mental model:

Layer	What it controls	Analogy
GRANT	Can this role access the table at all?	The keycard that opens the building
RLS Policy	Which rows can this role see?	Which floors that keycard can reach

Without a GRANT, the keycard doesn't work. PostgreSQL's PostgREST layer turns you away at the door before RLS even runs. You can have perfectly written policies and they will never be evaluated — because the role was never let in to begin with.

This is why you can get permission denied for table user_roles even with the service_role key — the key that's supposed to bypass everything. Without explicit GRANTs, "supposed to bypass everything" turns out to have an asterisk.

The fix is two lines that most Supabase tutorials never show you:

GRANT ALL ON public.user_roles TO service_role, authenticated;
GRANT ALL ON public.profiles TO service_role, authenticated;

That's it. Two lines of SQL that most migration guides don't include.

The Migration Template You Should Steal

Every time you create a table in Supabase, this is the full pattern. Save it as a GitHub Gist. Tattoo it somewhere:

-- 1. Create the table
CREATE TABLE public.my_table (
  id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
  created_at TIMESTAMPTZ DEFAULT now()
);

-- 2. Enable RLS
ALTER TABLE public.my_table ENABLE ROW LEVEL SECURITY;

-- 3. Write your policies
CREATE POLICY "authenticated_can_select"
  ON public.my_table
  FOR SELECT TO authenticated
  USING (true);

-- 4. THE PART EVERYONE FORGETS
GRANT ALL ON public.my_table TO service_role, authenticated;
GRANT SELECT ON public.my_table TO anon;

Step 4 is not optional. It's not an edge case. It is required every single time, and the dashboard will not remind you.

The 60-Second Diagnostic

Hit permission denied and not sure why? Run these three queries in the Supabase SQL editor:

-- Is RLS actually enabled?
SELECT relname, relrowsecurity
FROM pg_class WHERE relname = 'your_table_name';

-- Do your policies exist?
SELECT policyname, cmd, roles
FROM pg_policies WHERE tablename = 'your_table_name';

-- Do GRANTs exist? (this is usually the missing one)
SELECT grantee, privilege_type
FROM information_schema.table_privileges
WHERE table_name = 'your_table_name';

If the third query returns nothing for service_role or authenticated — you found it.

Gotcha 2: The Race Condition Nobody Mentions

This one is subtler and it shows up as a UI flicker — your app briefly flashes an "account pending" or "access denied" screen for a user who is fully verified and approved.

It's not a database problem. It's a timing problem.

When a user logs in, your frontend is doing at least two async things at once: confirming the auth session exists, and fetching the user's role from the database. If your UI renders before the role fetch completes, it sees role = null for a split second and acts accordingly — showing whatever your "no role" fallback state is.

The common mistake is initialising the loading state as false:

// This is the trap
const [roleLoading, setRoleLoading] = useState(false);

false means "done loading." Your UI reads that and renders immediately, before the role has arrived.

The fix is using null as the initial state instead:

// null = "I genuinely don't know yet — don't render anything"
const [roleLoading, setRoleLoading] = useState(null);

null means "ask me later." Your UI holds. The role arrives. The correct screen renders. No flicker.

It's a one-character change — false to null — that's the difference between a UI that lies to users for 200ms and one that waits until it knows the truth.

Why This Happens With BaaS Platforms Specifically

Both of these issues share a root cause: Supabase abstracts so much so well that it's easy to stop thinking about the layer underneath.

The dashboard gives you toggles. The client library gives you clean methods. The auto-generated APIs give you something that feels like it's handling everything. And mostly it is — until it isn't, and the failure is silent, and the symptom looks identical whether the problem is a missing GRANT or a race condition or something else entirely.

This isn't a criticism. The abstraction is genuinely the point, and it's genuinely good. But every abstraction has a floor. With Supabase, the floor is PostgreSQL — and PostgreSQL has opinions.

The moment you remember that Supabase is PostgreSQL with excellent packaging, a lot of otherwise mysterious behaviour starts making sense.

The Pre-Launch Auth Checklist

Before you ship any Supabase auth flow:

[ ] Every table has both RLS policies and GRANT statements
[ ] Role/loading state initialises as null, not false
[ ] Tested clean: run npx supabase db reset --local from scratch at least once
[ ] Tested with both anon key and service_role key separately

That third one matters more than it looks. If you've only ever run your app against a database that was built incrementally and never torn down, you haven't found all your migration gaps yet. A clean reset is the smoke detector.

Hit a Supabase gotcha that this doesn't cover? Drop it in the comments — these things rarely travel alone. 👇

Backend engineer. I write about the bugs I actually hit. Portfolio: cycy.is-a.dev 🚀

Usipoziba Ufa, Utajenga Ukuta — On Technical Debt and the Discipline to Fix It

cynthia wahome — Mon, 16 Mar 2026 11:59:47 +0000

There's a Swahili proverb that lives in my head rent-free as a developer:

Usipoziba ufa, utajenga ukuta.
If you don't seal the crack, you'll rebuild the wall.

I was recently doing a technical review of a school management system — a real, live, production codebase built by a team moving fast and shipping features. The kind of project where prototyping decisions become permanent ones, and technical debt quietly accumulates in the walls.

I could have done the minimum. Fixed what was on the ticket, shipped, moved on. Instead I did what I always do — I kept pulling the thread.

Here's what I found, and the first principles behind every fix.

Context (Because You Deserve It)

This was a PHP/Laravel backend — a language I was relatively new to at the time. Laravel is a popular PHP web framework, and Tinker is its interactive console, like a REPL you can use to query and manipulate the database directly without building a UI. Think of it as a surgical tool for backend diagnosis.

The system managed multiple schools on one platform (multi-tenancy), had just added a sales agent referral program, and needed a security and UX audit before the next release.

I wasn't here to judge the original code. Prototyping leaves debt — that's not incompetence, that's software. My job was to leave it better than I found it.

Screenshots and PR references: [link to PRs here when publishing]

1. Seal the Crack Before You Need a New Wall

The most critical find: a single helper method with a dangerous fallback.

The system was supposed to identify which sales agent was making a request by checking their login session. Correct. But if that check failed — instead of stopping — it fell back to reading an agent_id value straight from the URL.

Anyone. Any authenticated user. Could type ?agent_id=someone-elses-id in the URL and gain full access to that agent's dashboard, commissions, and payout history.

The fix was one line. But the lesson is about what happens when you don't fix it: a crack becomes a wall you eventually have to rebuild entirely — after the breach.

The principle: User input is untrusted. Always. URL parameters, form fields, headers, cookies — all of it can be faked. Never use client-supplied data to make an authorisation decision. This is not a PHP principle. This is not a Laravel principle. It is a law of the internet.

2. Never Break the Architecture to Solve One Edge Case

This was the most architectural moment of the whole review.

The system needed a Global Super Admin — someone who could see all agents across all schools. Problem: every user in this system is physically tied to a specific school in the database. That's the security contract. And it's enforced at the database level, not just in code.

The tempting fix: make the school_id column nullable. One migration, problem solved.

I almost did it. Then I stopped.

Making that column nullable wouldn't just solve this one case — it would quietly weaken the security guarantee for every school on the platform. The whole point of the design was that cross-school data leaks are structurally impossible. One nullable exception and that guarantee has a crack in it.

The actual solution: create a real management entity — "Platform HQ" — and make the Super Admin belong to it. The architecture stays intact. The admin has a valid home in the system. No nullable columns. No broken contracts.

Own the strongest room inside the walls. Don't remove the walls.

This transcends PHP, Laravel, any framework. Whenever you're about to modify a database schema to accommodate a single edge case — pause. Ask whether the edge case can be made to fit the existing contract instead.

3. Guard the Exit, Not the Entrance

A product decision dressed as a security question: should agents who sign up via Google OAuth be blocked from the dashboard until an admin manually approves them?

The security case for blocking: obvious. Unverified users shouldn't see sensitive data.

The product case against: onboarding friction at the highest-intent moment is how you lose users. Someone who just signed up via Google and immediately hits a wall will leave. You've completed their registration and immediately punished them for it.

The solution: guard the exit, not the entrance.

Let them in. Let them see the dashboard. Let them understand the product and start generating referrals. But the payout service — where money actually moves — requires approval before it runs.

This is applicable everywhere a payment or financial feature sits behind a registration flow. Google OAuth (or any SSO) is a legitimate, convenient way to onboard users. The mistake is assuming that authentication and authorisation are the same thing. They're not. Authentication says who you are. Authorisation says what you're allowed to do.

Lock the vault. Leave the lobby open.

4. The Bug That Only Existed in Production

A "Ghost Object" bug — one of the more disorienting things you'll encounter.

The dashboard "Approve Agent" button returned an error saying the agent wasn't in the right status. I checked directly in Tinker — the status was correct. So why was the controller seeing null?

Diagnosis via logs showed the entire agent object was empty. The server received the ID from the URL but never fetched the actual record.

Root cause: the admin routes were wired up manually in a way that bypassed the standard API middleware. Route Model Binding — the feature that automatically resolves URL parameters into database records — only runs inside that middleware. Without it, the server got an ID and did nothing with it.

The principle: "Works in local tooling" and "works in the API" are not the same test. Your REPL, your console, your local scripts — they run in a different context than your actual request lifecycle. When something works in one and fails in the other, look at what the request pipeline does that your tooling skips.

5. Harden Your Logic Against Its Environment

This one is underrated. We added trim() and strtolower() to status comparisons in the data model — not because users were submitting messy input, but because different database engines handle string comparison differently.

Postgres is strict. MariaDB can be inconsistent about trailing whitespace and case sensitivity depending on configuration. An internal state machine that depends on string equality needs to be immune to the floor beneath it.

The principle: Write code that's correct regardless of the environment it runs in. Defensive logic isn't paranoia. It's acknowledging that you don't control every variable between your code and the database driver.

What I Actually Came For

I came in to add some UI banners. I left having:

Closed a privilege escalation hole
Preserved a multi-tenancy security contract that almost got weakened
Fixed a ghost object caused by misconfigured middleware
Moved an auth check from the wrong door to the right door
Hardened string comparisons against database inconsistency
Opened issues, flagged technical debt, and added milestones so none of it gets lost

That last point matters. I could have fixed my ticket and left. But I logged everything else I found — as issues, as notes, as future work. Because debt you've seen and documented is manageable. Debt you've seen and ignored is a wall waiting to be rebuilt.

I'm naturally curious. I'm not afraid of bugs — they're how I learn. And I genuinely enjoy taking a codebase that's been moving fast and making it move more safely.

Cyfamod Technologies · GitHub

Cyfamod Technologies has 8 repositories available. Follow their code on GitHub.

github.com

The language was PHP. The principles aren't.

Usipoziba ufa, utajenga ukuta.

Seal the crack now. Or rebuild the wall later.

Backend engineer. I write about systems, architecture, and what I learn by poking at things. Portfolio: cycy.is-a.dev 🚀

It Ran Fine in Production. Then I Wrote the Tests.

cynthia wahome — Thu, 12 Mar 2026 21:01:37 +0000

The app worked. Users could log in. Data was saving. Nobody was on fire.

So naturally, I went looking for the fire.

I was asked to audit a new Agent Referral feature on a school management system — agents refer schools, earn commissions, the usual. No brief. No checklist. Just "make sure it's fine."

It was not fine. Nothing was visibly broken, but the architecture had been quietly making peace with some genuinely bad decisions. Everything held together by vibes and accumulated runtime state.

Here's what I found — and why it matters whether you're writing PHP, Python, Go, or whatever language you've convinced yourself won't betray you.

The Back Door That Was Literally Labelled

There was a helper method — resolveAgent() — whose job was to figure out which agent was logged in. Two steps:

Check if the authenticated user is an Agent ✅
If not — check if the URL has an agent_id parameter, and if so, load that agent from the database ❌

Step 2 is called Privilege Escalation. Any authenticated user — a school admin, a teacher, literally anyone — could type ?agent_id=some-uuid into the URL and gain full access to that agent's dashboard, commissions, and payout history.

The fix was one line:

return $user instanceof Agent ? $user : null;

You're an agent or you get nothing. No fallbacks. No trusting what someone typed in a URL.

The principle: Never trust the client. Anything arriving from a browser — URL params, form fields, headers, cookies — can be faked. Assume it is. This isn't a PHP rule or a Laravel rule. It's a law of the internet, as immovable as gravity and significantly less forgiving.

The Database That Only Looked Stable

To prove my fix worked, I wrote tests. Ran them. The whole suite detonated before a single test executed — the database couldn't rebuild itself from the migration files.

Two issues:

Issue 1: A migration tried to set a default value on a TEXT column. TEXT is unbounded — think of it as an essay answer sheet with no word limit. The database's response was essentially "I'm not pre-filling every essay box. That's expensive and I refuse." MariaDB won't allow it. MySQL might let it slide depending on config. They're like twins — 99% identical, except MariaDB read the rulebook.

Issue 2: A composite primary key included a nullable column. A primary key is the database's ID badge for a row. An ID badge that might be blank can't identify anything. The database said no. Correctly.

The wild part? The production app was running fine. The database had been built incrementally over months, never torn down. My tests used RefreshDatabase — which destroys everything and rebuilds from scratch every run. That clean slate exposed every shortcut that had been quietly accumulating.

It's like a building that looks solid because nobody's pulled up the floorboards in years.

The principle: Your code isn't portable until it survives a clean build. If your app only works because the database was assembled "just right" and nobody's had to start fresh — that's not stability, that's a patient time bomb.

The Vault and the Clerk

Once the database rejected the defaults, I had to put them somewhere else. Which raised the interesting question: where do defaults belong?

Think of your backend as a bank:

The vault (the database): stores things safely. Doesn't think. Doesn't decide.
The clerk (the application): handles logic. Decides what to fill in when nobody specified.

The original code was asking the vault to think. The vault refused.

I moved the defaults to the Model layer — the part of the code that defines what a "Term Summary" actually is:

protected $attributes = [
    'overall_comment' => 'This student is good.',
    'principal_comment' => 'This student is hardworking.',
];

Now the application handles the logic. The database just stores. Swap Postgres for MySQL tomorrow — the defaults don't care. Rewrite the frontend entirely — the backend doesn't notice.

The principle: Separation of Concerns. Each layer minds its own business. The systems that survive change are the ones where nobody's doing someone else's job.

Tests Are Receipts, Not Optional

I wrote eight tests. One Factory to generate realistic fake data. Then:

5 security tests: a school admin tries every angle to access an agent's dashboard. Every single one returns 401 Unauthorized.
3 auth tests: agents can still register, log in, get rejected with the wrong password. The front door still works.

"I fixed it" is a belief. Eight green checkmarks are evidence.

Six months from now when someone asks "are we certain a school admin can't get into agent data?" — the answer isn't a Slack message. It's a test suite that runs every time someone touches that code.

Tests are documentation that doesn't go stale and can't be misremembered.

The Part Worth Keeping

Two things kept surfacing and they're worth separating cleanly:

First Principles are the physics — the laws that don't change regardless of framework or language:

User input is untrusted. Always.
A primary key that might not exist can't identify anything.
A database won't efficiently enforce constraints it wasn't built for.

Design Patterns are the blueprints that implement those laws:

Zero trust → authentication guards, no URL parameter fallbacks
Defaults the database won't hold → move them to the Model
Prove it works → Factories and tests

The pattern is the tool. The principle is why you pick it up.

Three questions worth asking about every system you touch:

Who owns this responsibility? If the answer isn't obvious, that's the bug.
What is actually, fundamentally true here? Strip the assumptions.
Can you prove it? If not, you don't know — you just haven't been wrong yet.

The recipes change. The physics don't.

Drop a comment — genuinely curious: what's the worst "it worked in production" moment you've walked into? The more specific the horror, the better. 👇

Backend engineer. I write about systems, architecture, and what happens when you poke at things that were better left unexamined. Portfolio: cycy.is-a.dev 🚀

The is-a.dev + Vercel Field Guide: Every Pitfall, Mapped

cynthia wahome — Fri, 06 Mar 2026 10:40:03 +0000

Free .is-a.dev subdomains are genuinely one of the better things the dev community has built. Clean URL, no cost, no registrar drama. The whole process is submitting a JSON file via GitHub Pull Request.

Here's the part nobody front-loads: the repo runs automated CI tests on every PR before a human even looks at it. Fail those, and you're already closed before a reviewer blinks. Pass those, and then a real human volunteer visits your site and reviews your files.

Two gates. Different failure modes. This guide covers both.

Step 0: Check Availability Before Anything Else

👉 https://is-a.dev

Search your name. Takes 10 seconds. Do it before you get attached.

What You Need

GitHub account
A project live, deployed, and has actual content on Vercel — not a placeholder page
Vercel dashboard open at your project → Settings → Domains
A screenshot of your live site (the PR template requires this)

Step 1: Fork, Clone, Branch

git clone https://github.com/your-github-username/register.git
cd register
git checkout -b add-yourname-domain

Fresh branch every time. Don't work on main.

Step 2: Your Domain File

Create domains/yourname.json:

{
  "owner": {
    "username": "your-github-username",
    "email": "your-email@example.com"
  },
  "records": {
    "CNAME": "cname.vercel-dns.com"
  }
}

What the CI tests will catch here

record vs records — The CI schema validation flags record (singular) immediately. Your PR won't survive automated checks. It's records, plural, always.

Invalid JSON — A missing comma or unclosed brace and the CI fails. Validate at jsonlint.com before you push.

File in the wrong place — Must be inside domains/. Not the root, not a subfolder.

A records must be arrays — If you use an A record instead of CNAME, it has to be: "A": ["76.76.21.21"] — array syntax, even with one value.

CNAME + A in the same file — They conflict. CI will catch it. Pick one; for Vercel, CNAME is the right call since their IPs can change.

Self-referencing — A CNAME that points back to yourname.is-a.dev will also get caught.

Use CNAME over A record for Vercel. cname.vercel-dns.com is stable long-term.

Step 3: The Vercel Verification Pitfall 🚨

This is what gets people past CI but stopped by the human reviewer.

First — get your TXT token from Vercel

Your project needs to already be live and deployed. Then:

Vercel project → Settings → Domains → Add Domain
Enter yourname.is-a.dev
Vercel asks if you want to redirect to www.yourname.is-a.dev — do not enable this (more on why in a second)
Select the root domain only → click "Continue manually"
Copy the TXT string Vercel shows you:

vc-domain-verify=yourname.is-a.dev,sometoken123abc

Vercel shows "Invalid Configuration" immediately. That's expected — your PR isn't merged yet. Leave it.

Where NOT to put the TXT record

The obvious move: add the TXT record into yourname.json next to the CNAME. Tidy, logical, wrong.

is-a.dev requires verification records in their own dedicated file. For Vercel, that file is _vercel.yourname.json:

{
  "owner": {
    "username": "your-github-username",
    "email": "your-email@example.com"
  },
  "records": {
    "TXT": "vc-domain-verify=yourname.is-a.dev,your-token-from-vercel"
  }
}

You end up with two files:

File	Does what
`yourname.json`	Routes traffic to Vercel via CNAME
`_vercel.yourname.json`	Proves ownership to Vercel via TXT

One routes. One verifies. That's the unlock.

Step 3b: The WWW Redirect Trap 🪤

Back in Step 3 when Vercel asks about redirecting to www.yourname.is-a.dev — here's why you skip it:

www.yourname.is-a.dev is a completely separate subdomain. It needs its own JSON file and its own PR in the is-a.dev repo. If you enable the redirect without registering www, Vercel goes looking for a domain it can't find — and your site serves a 404 instead of your portfolio.

Worse: if you then try to remove the redirect and go back to the root domain, Vercel can get stuck demanding a new TXT verification token for the www subdomain before it lets you proceed. It's an annoying loop.

If you accidentally clicked it already:

Vercel → Project Settings → Domains
Find www.yourname.is-a.dev
Delete it 🗑️
Root domain only stays

Propagates in about 60 seconds. Back to normal.

Step 4: Submit the PR

git add domains/yourname.json domains/_vercel.yourname.json
git commit -m "feat(domain): add yourname.is-a.dev with Vercel CNAME and verification"
git push origin add-yourname-domain

Open a PR against is-a-dev/register. An automated welcome message appears when you do — read it. It tells you exactly what reviewers check. Short version:

Fill in the PR template — don't delete it or swap it out
Include a screenshot of your live site — not optional, reviewers look for it
Mention the domain is already added in Vercel

Reviewers are volunteers. A complete, clean submission is the only reliable fast path.

Full Pitfall Reference

What kills your PR	When it's caught	Fix
`record` not `records`	CI — automated	Fix the key, validate JSON
Invalid JSON syntax	CI — automated	Run through jsonlint.com
File outside `domains/`	CI — automated	Move it to the right folder
A record as a string not array	CI — automated	`"A": ["ip"]`
CNAME + A in same file	CI — automated	Pick one
CNAME pointing to itself	CI — automated	Don't self-reference
TXT token inside main domain file	Human reviewer	Move to `_vercel.yourname.json`
Domain added to Vercel but shows 404	Human reviewer	Add domain first, let Vercel sit in "pending"
No screenshot in PR description	Human reviewer	Add one
Site is under construction	Human reviewer	Finish it, then submit
`www` redirect enabled without registering `www`	Human reviewer / post-merge	Delete `www` entry in Vercel
PR goes stale after maintainer asks for changes	Administrative	Respond within a few days
Name already taken by a pending PR	Administrative	Check open PRs before submitting
Nested subdomain, parent doesn't exist	CI or reviewer	Register parent domain first

GitHub Pages? Same Pattern

{
  "owner": {
    "username": "your-github-username"
  },
  "records": {
    "CNAME": "your-github-username.github.io"
  }
}

Verification file: _github-pages-challenge-yourname.json — same structure, different prefix. The _platform.yourname.json naming convention applies across the board.

Pre-Submit Checklist

[ ] Name available at is-a.dev
[ ] Fresh branch off main
[ ] domains/yourname.json — CNAME, records plural, valid JSON
[ ] domains/_vercel.yourname.json — TXT token from Vercel
[ ] Domain added to Vercel Settings → Domains, root only, no www redirect
[ ] Site is live with real content
[ ] Screenshot of live site ready for PR description
[ ] PR template filled out, not replaced

After the Merge

Usually live within minutes. Still seeing the is-a.dev homepage after 15–20 min? Flush DNS:

# macOS
sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

# Linux
sudo systemd-resolve --flush-caches

# Windows
ipconfig /flushdns

Then enable Enforce HTTPS in Vercel. You have a clean URL now — secure it.

TL;DR

Check is-a.dev first
records — plural, or CI rejects you immediately
CNAME to cname.vercel-dns.com
Get TXT token: Vercel → project → Settings → Domains → Add Domain → Continue manually
TXT token goes in _vercel.yourname.json — separate file, not the main one
Root domain only in Vercel — skip the www redirect
Screenshot in the PR description

Two gates. Two files. Right keys. That's the whole thing.

Written by a developer who now has a working .is-a.dev domain and a portfolio full of backend projects to show for it — cycy.is-a.dev 🚀

this was a really fun drive 🚘 ...plus I totally love synthwave 😍 starting cursing here: https://sundaydevdrive.pilotronica.com contribute to the project here: https://github.com/georgekobaidze/sunday-dev-drive well done @Giorgi Kobaidze

cynthia wahome — Fri, 06 Mar 2026 06:55:25 +0000

DEV Weekend Challenge: Community

Giorgi Kobaidze

Mar 1

Sunday DEV Drive: A Synthwave Driving Experience Through Your DEV Community Articles

#showdev #devchallenge #weekendchallenge

Comments 23

10 min read

Sunday DEV Drive

Drive through your DEV Community articles in a synthwave world. Your posts become neon billboards along an endless road.

sundaydevdrive.pilotronica.com

GitHub - georgekobaidze/sunday-dev-drive: A synthwave driving experience through your DEV Community articles · GitHub

A synthwave driving experience through your DEV Community articles - georgekobaidze/sunday-dev-drive

github.com

Deep Dive: Resolving DNS Issues with GitHub and Understanding SSH vs HTTPS

cynthia wahome — Thu, 05 Mar 2026 10:39:57 +0000

Ever tried pushing your code to GitHub, only to be stopped by a timeout error that makes zero sense? That's exactly what happened to me — and what started as a frustrating blocker turned into a genuinely useful deep dive into DNS, network routing, and Git's connection methods. 🚀

Let me walk you through every step.

The Problem: GitHub, You're Killing Me 😩

Everything was going fine until I ran a routine push:

git push origin feat/add-tests

Instead of the usual success, I got:

fatal: unable to access 'https://github.com/your-username/your-repo.git/':
Failed to connect to github.com port 443 after 75079 ms: Couldn't connect to server

75 seconds of waiting, then nothing. Time to dig in. 🔍

Step 1: Is GitHub Actually Down? 🌐

Before blaming my own setup, I checked whether GitHub was reachable at all:

curl -s -o /dev/null -w "%{http_code}" https://github.com

The response? 000

A 000 status code from curl means the request never even got a response — no HTTP handshake, no connection, nothing. GitHub's HTTPS port was completely unreachable from my machine.

Step 2: Ping & DNS Lookup — Finding the Culprit 🕵️‍♂️

Ping test

$ ping -c 2 github.com
PING github.com (20.87.245.0): 56 data bytes
Request timeout for icmp_seq 0
64 bytes from 20.87.245.0: icmp_seq=1 ttl=114 time=72.940 ms

Packet loss right away. The IP 20.87.245.0 was responding inconsistently — not the behavior you'd expect from GitHub's infrastructure.

Note: Packet loss in a ping doesn't always mean slow internet. It often means the specific IP you're being routed to has a problem.

DNS lookup

$ nslookup github.com
Name:    github.com
Address: 20.87.245.0

There it was. DNS was resolving github.com to 20.87.245.0 — a broken or misrouted IP. Large services like GitHub use many IPs across their infrastructure. When DNS caching or propagation goes wrong, you can end up pointed at one that's temporarily dead.

Step 3: Port Check — Confirm It's Not Just a General Outage 🔌

To rule out a broader network issue, I checked whether GitHub's HTTPS port (443) specifically was blocked:

nc -zv github.com 443 -w 5

No connection. Port 443 was unresponsive via that IP.

But this raised an interesting question — if HTTPS (port 443) is blocked, what about SSH (port 22)? I kept that in mind for later.

Step 4: Traceroute — Where Is the Connection Actually Dying? 🗺️

Running a traceroute showed exactly where packets were getting dropped:

$ traceroute github.com
 1  192.168.x.x (192.168.x.x)    14.672 ms
 2  10.x.x.x (10.x.x.x)          9.098 ms
 3  * * *
 4  * * *
 5  * * *

(Local IPs anonymised)

Hops 1 and 2 — my local router and ISP gateway — responded fine. After that: silence. The connection was dying somewhere in the ISP's routing infrastructure, well before reaching GitHub's servers.

This is a classic sign of either:

A routing failure at the ISP level
Traffic being directed to a bad IP that simply drops packets

The DNS evidence from earlier made the latter the most likely culprit.

Step 5: Verify the Fix With a Known-Good IP 🧪

Before touching any system config, I tested whether the network itself was fine by bypassing DNS entirely:

curl --resolve github.com:443:140.82.121.3 https://github.com

This forces curl to connect to 140.82.121.3 (a legitimate GitHub IP) while keeping the hostname intact for TLS. The result? 200 OK. ✅

The network was fine. The problem was purely DNS returning a bad IP.

How to find legitimate GitHub IPs: Check https://api.github.com/meta — GitHub publishes their official IP ranges here.

Step 6: Override DNS via `/etc/hosts` 🔧

With the root cause confirmed, the fastest fix was to bypass DNS locally:

echo "140.82.121.3 github.com" | sudo tee -a /etc/hosts

Or edit the file manually:

sudo nano /etc/hosts
# Add this line:
140.82.121.3 github.com

This tells your OS: "Don't ask DNS where github.com is — I'm telling you directly."

After saving, GitHub loaded instantly in the browser. But the git push was still failing — because my remote was still using HTTPS.

Step 7: Switch Git Remote from HTTPS to SSH 🔑

Here's what I had been missing. Even with the /etc/hosts fix, port 443 was still being affected by the underlying routing issue. SSH uses port 22, which was completely unaffected.

Check your current remote:

git remote -v
# origin  https://github.com/your-username/your-repo.git (fetch)
# origin  https://github.com/your-username/your-repo.git (push)

Switch to SSH:

git remote set-url origin git@github.com:your-username/your-repo.git

Verify:

git remote -v
# origin  git@github.com:your-username/your-repo.git (fetch)
# origin  git@github.com:your-username/your-repo.git (push)

Then:

git push origin feat/add-tests
# ✅ Success

Here's a quick comparison of both methods:

Method	Port	Auth	Best For
HTTPS	443	Username + PAT token	Simple setups, one-off clones
SSH	22	SSH key pair	Frequent pushes, automation, CI/CD

SSH is worth setting up properly if you haven't — no tokens to rotate, no passwords to enter, and as this situation showed, port 22 is far less likely to be caught up in DNS/routing failures than 443.

Key Takeaways 💡

A curl status of 000 means zero connectivity — not a server error, not a redirect. Nothing got through.
DNS can return broken IPs. Large services like GitHub use many IPs. Caching issues can leave you pointed at one that's dead or misrouted.
Traceroute tells you where things break. If packets die at hop 3+, the issue is upstream of you — your ISP or beyond.
/etc/hosts is a surgical bypass tool. It skips DNS entirely for a specific hostname. Useful in emergencies, but remember to revert it once DNS is healthy again.
SSH over HTTPS for Git — always, if you can. It's more secure, needs no token management, and uses a different port that's often unaffected when HTTPS routes break.
Always verify IPs against official sources. Hardcoding a rogue IP in /etc/hosts is a real MITM vector. Use api.github.com/meta to confirm.

Full Troubleshooting Cheatsheet

# 1. Check if HTTPS is reachable at all
curl -s -o /dev/null -w "%{http_code}" https://github.com

# 2. Check DNS resolution
nslookup github.com

# 3. Test connectivity to a known-good IP without changing DNS
curl --resolve github.com:443:140.82.121.3 https://github.com

# 4. Check if port 443 is open
nc -zv github.com 443 -w 5

# 5. Trace where packets are dying
traceroute github.com

# 6. Override DNS locally
echo "140.82.121.3 github.com" | sudo tee -a /etc/hosts

# 7. Check your Git remote
git remote -v

# 8. Switch remote to SSH
git remote set-url origin git@github.com:your-username/your-repo.git

Conclusion

What looked like a random GitHub outage turned out to be a DNS routing failure — solvable with a two-line fix once you know what you're looking for. The traceroute and curl tests were the real turning point: they made the invisible visible, showing exactly where the connection was breaking and why.

If you take nothing else from this: learn to read traceroutes, and set up SSH for Git. Both have saved me hours of confusion.

Got questions, or your own DNS war stories? Drop them in the comments 👇

TL;DR

git push failed with a port 443 timeout
curl returned 000 — no connection at all
DNS was resolving GitHub to a broken IP (20.87.245.0)
Traceroute confirmed the failure was upstream, not local
Fixed short-term with /etc/hosts pointing to a working IP
Fixed properly by switching Git remote from HTTPS → SSH (port 22)

I resonate so much with this

cynthia wahome — Sun, 01 Mar 2026 18:34:40 +0000

The Hardest Part of Being a Developer Isn’t Coding. It’s Disappearing Quietly.

NorthernDev ・ Feb 28

#discuss #mentalhealth #webdev #career

I Almost Filed a Bug Report. Then I Pressed Ctrl+P

cynthia wahome — Sun, 01 Mar 2026 10:45:16 +0000

I was using Kilo CLI v7.0.33 and something felt off. I could scroll fine — but there was no scrollbar indicator. No sense of where I was in a long session. Other CLIs had it. Mine didn't.

My immediate take: the scrollbar is broken.

So I went digging.

The GitHub Rabbit Hole

I went through OpenCode issues, Kilo issues, anything mentioning scroll + Warp + iTerm. Left a couple of comments piecing together what I thought was happening:

scrollbars missing #2500

ubuntupunk posted on Sep 08, 2025

I can't seem to scroll up to read what opencode is outputting. I don't have this problem with gemini-cli and any other cli so its not terminal related. The opencode scrollbar is just a sold bar for some reason

View on GitHub

Cannot scroll on opencode when using iterm #6209

anugrahsinghal posted on Dec 26, 2025

Description

When trying to scroll the opencode TUI on iterm, it scrolls the input box but not the output of the previous command

OpenCode version

1.0.203

Steps to reproduce

Install iTerm2
opencode
!ls # to see basic output - should be long enough to overflow from view
scroll

Screenshot and/or share link

https://github.com/user-attachments/assets/eea1ae7e-6401-4ef8-b30d-d5265fee28ca

Operating System

26.2

Terminal

iTerm2

View on GitHub

The threads were noisy but a pattern emerged — people were actually describing two different problems and conflating them:

Problem 1 — Mouse scroll not working at all (terminal layer)
Warp and iTerm need Mouse Reporting enabled before they'll forward scroll events to a full-screen TUI. Without it, your scroll wheel just doesn't reach the app. Fix is in terminal settings.

Problem 2 — Scrollbar not visible (app layer)
Completely separate. Scroll events arriving fine, but the indicator is just... off.

I had Problem 2. But the GitHub threads mostly discussed Problem 1.

Here’s what it looked like in my terminal — no visible scrollbar, long output, no sense of position and it was consistent in all the themes!

At this point, I was convinced it was broken.

Wait, What Am I Even Running?

Before assuming anything, I needed to understand the actual architecture. Kilo isn't just OpenCode — it's a fork:

So I went to the source.

Buried in the session route, I found it. The scrollbar wasn’t missing at all — it was disabled by default. A KV-backed feature flag, persistent across sessions, but initialized to false.

I was one tab away from opening an enhancement issue.

Inside:

opencode/packages/opencode/src/cli/cmd/tui/routes/session/index.tsx

const [showScrollbar, setShowScrollbar] = kv.signal("scrollbar_visible", false)

And later:

verticalScrollbarOptions={{
  visible: showScrollbar(),
}}

That was the moment everything clicked.

The scrollbar existed.
It was toggleable.
And by default — it was off.

Then I Pressed Ctrl+P

Command Palette. I typed "scroll."

Toggle session scrollbar

I pressed it. The scrollbar appeared.

It had been there the whole time.

What This Actually Was

Not a bug. Not a missing feature. A discoverability gap.

The scrollbar is implemented, toggleable, persistent — just hidden behind a keybind nobody thinks to try when they're confused about scroll behavior. That's a UX conversation worth having with maintainers, not a bug report.

After piecing everything together, I went back to the GitHub threads.

Instead of filing a new issue, I left a couple of comments clarifying what I’d found — separating the terminal mouse-reporting problem from the scrollbar visibility toggle. A small thing, but hopefully useful signal in a noisy thread.

Sometimes contributing isn’t about opening something new.
It’s about tightening what already exists.

The Real Takeaways

Separate layers before blaming. Terminal config and app state are different things. Conflating them sends you in circles.

Read source before filing. That false default was right there. Five minutes of reading saved a maintainer from triaging noise.

Forks are their own thing. Upstream behavior isn't a reliable guide. Check what the fork actually exposes.

Discoverability is a real problem. If multiple users independently can't find a feature, that's signal — even if the feature works perfectly.

Quick Fix if You're Here for the Answer

Scroll not working at all → enable Mouse Reporting in your terminal settings
Scroll works but no scrollbar → Ctrl+P → search "scrollbar" → toggle on

It'll persist across sessions once set.

Flutter Development Environment Setup (Apple Silicon macOS)

cynthia wahome — Tue, 10 Feb 2026 18:55:35 +0000

This document is a complete, reproducible guide based on a real troubleshooting journey. It explains what we were trying to achieve, why each tool exists, how to install everything cleanly, and how to debug the exact problems we encountered.

It is designed so that you can:

Uninstall everything
Reinstall from scratch
Understand why each step exists
Recover quickly if something breaks again

1. Goal: What We Were Trying to Achieve

We wanted a stable Flutter development environment on Apple Silicon macOS that can:

Build and run an existing Flutter Android app (using a physical Android device)
Compile and run the same Flutter codebase for iOS
Build and run the app as a native macOS desktop app
Avoid Android emulators (low-RAM optimization)
Be repeatable and understandable

2. Mental Model: How the Tools Fit Together

Flutter

The orchestrator
Reads your Dart code
Decides which platform you are targeting
Delegates work to platform-specific tools

Dart

The programming language of your app
Bundled with Flutter (you don’t install it separately)

Android Studio

Not required to build Flutter apps
Used mainly to:
- Download Android SDK components
- Manage SDK versions
- Debug Android-specific issues

Android SDK

Required to build Android apps
Contains:
- adb (talks to your Android phone)
- build-tools
- platform-tools

Android Command-Line Tools

Provide sdkmanager
Required for:
- Accepting Android licenses
- Verifying SDK correctness
Flutter depends on these directly

Java (JDK)

Android build tools are written in Java
Required for:
- sdkmanager
- Gradle builds
Java must be visible to macOS (JAVA_HOME must be correct)

Xcode

Required for any iOS or macOS build
Provides:
- iOS simulator
- macOS compiler
- Code signing

CocoaPods

iOS dependency manager
Required because Flutter plugins include native iOS code

3. Clean Install Order (Recommended)

3.1 Install Xcode

Install Xcode from the App Store
Open Xcode once
Accept license:

   sudo xcodebuild -license accept

Install command-line tools:

   xcode-select --install

3.2 Install Homebrew

/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

Add to PATH (Apple Silicon):

echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> ~/.zprofile
eval "$(/opt/homebrew/bin/brew shellenv)"

3.3 Install Java (Android requirement)

Install Java 17:

brew install openjdk@17

Make macOS aware of Java:

sudo ln -sfn \
  /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk \
  /Library/Java/JavaVirtualMachines/openjdk-17.jdk

Set JAVA_HOME dynamically:

echo 'export JAVA_HOME=$(/usr/libexec/java_home)' >> ~/.zshrc
echo 'export PATH="$JAVA_HOME/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc

Verify:

java -version
/usr/libexec/java_home

3.4 Install Flutter (Official ZIP – NOT Homebrew)

Download Flutter macOS Apple Silicon zip
Extract via Terminal (avoid Finder quarantine issues):

   cd ~/Downloads
   unzip flutter_macos_arm64*.zip
   mv flutter ~/development/

Remove quarantine:

   xattr -dr com.apple.quarantine ~/development/flutter

Add to PATH:

   echo 'export PATH="$PATH:$HOME/development/flutter/bin"' >> ~/.zshrc
   source ~/.zshrc

Verify:

   flutter --version

3.5 Install Android Studio

Download Apple Silicon version
Drag Android Studio.app into /Applications
Remove quarantine:

   sudo xattr -dr com.apple.quarantine "/Applications/Android Studio.app"

Launch Android Studio

3.6 Install Android SDK + Command-Line Tools

In Android Studio:

Open SDK Manager
Set SDK location:

   /Users/<your-user>/Library/Android/sdk

Install:

Android SDK Platform
Build-Tools
Platform-Tools
Command-line Tools (latest)

Verify:

ls ~/Library/Android/sdk/cmdline-tools/latest/bin/sdkmanager

Set environment:

echo 'export ANDROID_HOME="$HOME/Library/Android/sdk"' >> ~/.zshrc
echo 'export PATH="$PATH:$ANDROID_HOME/platform-tools:$ANDROID_HOME/cmdline-tools/latest/bin"' >> ~/.zshrc
source ~/.zshrc

Accept licenses:

flutter doctor --android-licenses

3.7 Install CocoaPods (iOS requirement)

brew install cocoapods
pod --version

3.8 Install iOS Simulator Runtime

In Xcode:

Xcode → Settings → Components
Install latest iOS Simulator runtime

Verify:

xcrun simctl list runtimes

4. Building Your Flutter App

Android (Physical Device)

flutter run -d android

iOS (Simulator)

cd ios
pod install
cd ..
flutter run -d ios

macOS Desktop

flutter config --enable-macos-desktop
flutter pub get
flutter run -d macos

Release build:

flutter build macos

5. Troubleshooting Reference (Problems We Solved)

Problem: “dart is damaged and can’t be opened”

Cause: macOS quarantine
Fix:

xattr -dr com.apple.quarantine ~/development/flutter

Problem: Android SDK exists but Flutter can’t find it

Cause: Missing command-line tools
Fix: Install cmdline-tools/latest and verify sdkmanager

Problem: `sdkmanager` exists but fails with JAVA_HOME error

Cause: Homebrew Java not visible to macOS
Fix: Symlink Java into /Library/Java/JavaVirtualMachines and set JAVA_HOME dynamically

Problem: `/usr/libexec/java_home` returns nothing

Cause: Java installed but not registered with macOS
Fix: Manual symlink (see Java section)

Problem: Android Studio installed but no SDK directory

Cause: SDK Manager never ran
Fix: Install SDK via Android Studio → SDK Manager

Problem: iOS simulator missing

Cause: No simulator runtime downloaded
Fix: Xcode → Settings → Components → Install iOS runtime

Problem: Chrome warning in `flutter doctor`

Meaning: Only affects Flutter Web
Fix (optional): Set CHROME_EXECUTABLE to Brave or install Chrome

6. Key Takeaways

Flutter is the coordinator, not the builder
Android Studio is optional but useful
Java is critical for Android builds
macOS security (Gatekeeper) causes most install pain
Once installed correctly, daily Flutter work is simple

7. Final Verification

Run:

flutter doctor

You should see:

Flutter ✓
Android toolchain ✓
Xcode ✓ (after simulator install)

This guide reflects a real-world, non-ideal setup path, which makes it far more valuable than a clean tutorial. You now understand not just how to install Flutter — but why it breaks and how to recover.

From Clone to iPhone: A First-Time Flutter iOS Journey (with All the Pitfalls)

cynthia wahome — Tue, 10 Feb 2026 18:53:48 +0000

This post documents my first real interaction with Flutter, Dart, Android Studio, Xcode, and iOS development, starting from cloning an existing Flutter repository all the way to running the app on a real iPhone.

It is intentionally long, explicit, and honest. If you want a clean tutorial, this is not it. If you want a real-world reference you can redo from scratch and debug when things go wrong, this is.

1. Context & Goal

I did not start this project to learn Flutter in isolation.

The real goal was:

Take an existing Flutter app from GitHub
Build and run it for Android (already working)
Compile and run it for iOS
Eventually share it with testers (students)

Hardware & constraints:

macOS (Apple Silicon)
Physical Android device available
iPhone available
No Apple Developer paid account initially

2. The Repository

The starting point was an existing Flutter repository:

cd ~/development
git clone https://github.com/Cyfamod-Technologies/school-app-flutter.git
cd school-app-flutter

At this point:

Android version already ran
iOS/macOS had never been built on this machine

3. First Run: macOS Desktop (Sanity Check)

Before touching iOS, I verified the Flutter toolchain by running the macOS desktop target:

flutter config --enable-macos-desktop
flutter pub get
flutter run -d macos

What happened

The app built successfully
A desktop window opened
The UI rendered
A connectivity warning appeared (from app logic, not Flutter)

Key lesson

Running on macOS does not mean iOS. Flutter supports multiple targets from the same codebase, but each platform is a separate build pipeline.

4. Understanding the Tools (Critical Mental Model)

Before continuing, this mental model is essential:

Flutter: Orchestrator (decides what to build)
Dart: Application language
Android Studio: SDK manager & Android tooling
Android SDK + Java: Required for Android builds
Xcode: Required for any iOS/macOS build
CocoaPods: iOS dependency manager

Flutter does not replace Xcode. It uses it.

5. Running on iOS Simulator

Step 1: Launch the simulator

open -a Simulator

Verify Flutter sees it:

flutter devices

Step 2: Run the app on iOS

flutter run -d "iPhone 16e"

Result

iPhone simulator opened
App launched
Login screen worked

Key lesson

The iOS simulator is excellent for learning and UI work, but it does not enforce Apple’s distribution rules.

6. Attempting to Run on a Real iPhone

This is where most first-time iOS developers hit the wall.

Initial error

The app identifier "com.example.myApp" cannot be registered
No profiles for 'com.example.myApp' were found

What this actually means

com.example.* is a placeholder bundle identifier
Apple requires globally unique bundle IDs for real devices

Fix: Set a unique Bundle ID

In Xcode:

open ios/Runner.xcworkspace

Then:

Select Runner → Signing & Capabilities
Change Bundle Identifier from:

   com.example.myApp

to something unique, e.g.:

   com.yourname.schoolapp

Enable Automatically manage signing
Select your Apple ID as the Team (free account is enough)

7. Installing on a Real iPhone (Debug Build)

With the bundle ID fixed:

Plug in iPhone via USB
Unlock and Trust This Computer
Enable Developer Mode on the iPhone

Run from Xcode:

Select the iPhone as destination
Click ▶️ Run

Result

App installed on the phone
App launched successfully

Important discovery

When the USB cable was removed, the app stopped opening.

This is expected behavior with free Apple IDs.

8. Debug vs Standalone vs Distribution (The Big Confusion)

Debug build (what free Apple ID gives you)

Installed via Xcode
Tied to the Mac
Often requires USB / debugger
Expires after ~7 days

Standalone distribution (what users expect)

Requires paid Apple Developer account:

TestFlight
App Store
Ad Hoc distribution

There is no workaround for this. This is an Apple platform rule, not a Flutter issue.

9. Why Running on a Real iPhone Still Mattered

Even though the simulator worked:

Real device exposed Apple’s signing model
Validated the project is technically viable
Proved the app can run on actual hardware
Surfaced distribution constraints early (good thing)

The simulator is for learning. The real device is for validation.

10. Cleaning Up (Pausing Safely)

Since iOS distribution was blocked by policy (not code):

Safe actions:

Shut down simulators
Close Xcode
Remove the app from the phone
Disconnect USB

Keep installed:

Flutter
Xcode
Android SDK
Java

This allows resuming later without reinstallation.

11. Troubleshooting Reference (What Broke & How It Was Fixed)

❌ "dart is damaged and can’t be opened"

Cause: macOS Gatekeeper quarantine
Fix:

xattr -dr com.apple.quarantine ~/development/flutter

❌ Android SDK found but Flutter can’t accept licenses

Cause: Missing cmdline-tools
Fix:

Install Android command-line tools
Ensure:

~/Library/Android/sdk/cmdline-tools/latest/bin/sdkmanager

❌ `JAVA_HOME` invalid / sdkmanager fails

Cause: Homebrew Java not registered with macOS
Fix:

sudo ln -sfn /opt/homebrew/opt/openjdk@17/libexec/openjdk.jdk \
/Library/Java/JavaVirtualMachines/openjdk-17.jdk

❌ iOS app won’t install on real phone

Cause: Placeholder bundle ID
Fix: Set a unique bundle identifier in Xcode

❌ App stops working when USB is unplugged

Cause: Free Apple ID limitations
Fix: Requires paid Apple Developer account for distribution

12. Final Takeaways

Flutter is powerful, but platform rules still apply
iOS development is as much about policy as code
The simulator is enough to learn
Real devices are required to ship
Apple’s $99 fee is not optional for real distribution

Most importantly:

Hitting these problems early is a sign you’re doing real development, not toy tutorials.

13. What I Would Do Next (If Starting Again)

Learn UI & logic on iOS Simulator
Validate once on a real iPhone
Decide early whether TestFlight is required
Budget Apple Developer account if yes
Ship calmly

This document exists so I can redo this entire process from scratch without guessing, and so other developers can avoid losing days to the same hidden traps.

Cloning Private GitHub Repositories on a Server (The Right Way, With SSH)

cynthia wahome — Sat, 31 Jan 2026 08:05:57 +0000

At some point, most developers hit this wall:

You’re logged into a server, you run:

git clone git@github.com:your-org/your-repo.git

…and Git responds with:

Permission denied (publickey).
fatal: Could not read from remote repository.

You know the repo exists.
You know you have access.
So what gives?

This post walks through why this happens, and how to fix it cleanly and securely, without leaking credentials or cutting corners.

The Core Problem (In Plain English)

GitHub doesn’t care who you are.
It cares which SSH key you’re presenting.

When you run git clone from a server:

GitHub sees an SSH key
It checks whether that key is authorized
If it doesn’t recognize it → access denied

That’s it. No magic.

Step 1: Understand What Machine You’re On

There are three identities involved:

Your laptop (already authenticated with GitHub)
Your server (a completely different machine)
A Linux user on that server (e.g. app, bot, or deploy)

Even if:

the repo is yours
your laptop has access
you’re “the same person”

👉 The server has its own identity.

You must explicitly grant it access.

Step 2: Generate an SSH Key on the Server

Log into the server as the user that will run the project:

ssh app@your-server-ip

Then generate a new SSH key:

ssh-keygen -t ed25519 -C "app-server-repo-access"

When prompted:

Press Enter to accept the default location
Leave the passphrase empty (recommended for non-interactive servers)

This creates:

~/.ssh/id_ed25519        (private key)
~/.ssh/id_ed25519.pub    (public key)

Step 3: Copy the Public Key

Display the public key:

cat ~/.ssh/id_ed25519.pub

You’ll see a single line starting with:

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAI...

Copy the entire line.

Step 4: Add the Key to GitHub (Deploy Key Method)

This is the recommended approach for servers.

In GitHub:

Open the repository
Go to Settings
Click Deploy keys
Click Add deploy key
Give it a name (e.g. app-server)
Paste the public key
Enable write access only if the server needs to push
Save

This key now:

works only for this repo
cannot access anything else
is safe to revoke anytime

Step 5: Test SSH Connectivity

Back on the server:

ssh -T git@github.com

If successful, you’ll see something like:

Hi! You've successfully authenticated, but GitHub does not provide shell access.

That’s a good thing.

Step 6: Clone the Repository

Now retry:

git clone git@github.com:your-org/your-repo.git

This time, it should work without errors.

Common Pitfall: “But I Can Clone From My Laptop”

That’s expected.

Your laptop:

has its own SSH key
already registered with GitHub

Your server:

is a different machine
needs its own key

SSH access is machine-based, not user-based.

Alternative: HTTPS (When It Makes Sense)

If the repo is public, you can always do:

git clone https://github.com/your-org/your-repo.git

For private repos, HTTPS requires:

a GitHub token
storing credentials on the server

For long-running services, SSH deploy keys are cleaner and safer.

Why This Setup Is Best Practice

Using deploy keys means:

no shared credentials
no copying laptop keys to servers
repo-scoped access
easy rotation and revocation

This is how CI systems, deployment bots, and production servers are meant to work.

Final Takeaway

If git clone fails on a server, it’s almost never a Git issue.

It’s an identity issue.

Once you understand that:

Servers authenticate themselves to GitHub using SSH keys,

the fix becomes straightforward, secure, and repeatable.

Happy deploying 🚀

SSH Like a Pro: Creating an Isolated User on an EC2 Instance (Without Breaking Anything)

cynthia wahome — Sat, 31 Jan 2026 08:05:09 +0000

If you’ve ever deployed more than one project on a single server, you’ve probably felt this tension:

“I don’t want this new thing to interfere with what’s already running.”

That’s exactly the situation I found myself in.

I had:

an existing EC2 instance
a main user running a larger project
and a new, smaller service I wanted to deploy cleanly and safely

The solution wasn’t Docker or Kubernetes.

It was something much simpler — Linux users + SSH keys, done properly.

This post walks through:

why creating a separate user matters
how SSH authentication actually works
and how to log in as a new user securely, without passwords

The Goal

I wanted to:

create a new Linux user (cc)
isolate a new project under that user
log in directly as cc using SSH
keep everything secure and professional

No hacks. No shortcuts.

Step 1: Create a New User

First, SSH into the server as your existing user:

ssh your-current-user@your-ec2-ip

Then create a new user:

sudo adduser cc

You’ll be prompted to set a password and optional user details.
You can safely skip the extra fields.

Optionally (but recommended), give the user sudo access:

sudo usermod -aG sudo cc

At this point, cc exists — but you cannot SSH into it yet.

Step 2: Understand What SSH Actually Authenticates

This is where most confusion happens.

SSH does not authenticate repositories.
It does not authenticate servers.
It authenticates users.

More specifically:

SSH proves that you own a private key, and the server checks whether the matching public key is allowed to log in as a specific Linux user.

Each user has their own allowlist:

~/.ssh/authorized_keys

If a public key is not listed there → no login.

A brand-new user like cc has an empty allowlist.

Step 3: Identify the Correct SSH Key

On your local machine, test your existing SSH connection with verbosity enabled:

ssh -v your-current-user@your-ec2-ip

Look for a line like:

Offering public key: ~/.ssh/backend-key

This tells you:

which private key your laptop is using
and therefore which public key represents you

The matching public key is:

~/.ssh/backend-key.pub

This is the only key you should use.

Step 4: Allow That Key to Log In as `cc`

On the server, create the SSH directory for the new user:

sudo mkdir -p /home/cc/.ssh
sudo chmod 700 /home/cc/.ssh
sudo chown cc:cc /home/cc/.ssh

Now create the authorization file:

sudo nano /home/cc/.ssh/authorized_keys

Paste the entire contents of your local backend-key.pub file into it.

Then fix permissions (this part is critical):

sudo chown cc:cc /home/cc/.ssh/authorized_keys
sudo chmod 600 /home/cc/.ssh/authorized_keys

Step 5: Log In as the New User

From your local machine:

ssh cc@your-ec2-ip

If everything is set up correctly, you’re in 🎉

You can confirm with:

whoami
pwd

You should see:

cc
/home/cc

“Why Can I Log In Without a Password?”

This surprises a lot of people — but it’s actually the point.

You are not logging in “without authentication”.
You are authenticating with cryptography, not passwords.

SSH keys are:

resistant to brute force
resistant to phishing
industry standard in cloud environments

This is more secure than password-based SSH.

If you want extra protection:

disable password SSH entirely
keep passwords for sudo only

That’s how most production systems are set up.

Optional: Clean Up Your Local SSH Config

To keep things tidy, you can name this connection in ~/.ssh/config:

Host cc-ec2
    HostName your-ec2-ip
    User cc
    IdentityFile ~/.ssh/backend-key

Now you can simply run:

ssh cc-ec2

Clear, explicit, and hard to mess up.

Why This Setup Is Worth It

By doing this, you get:

full isolation between projects
separate environments and dependencies
smaller blast radius if something breaks
a setup that scales with you

You didn’t just “make SSH work”.

You set up your server the way professionals do.

Final Thoughts

This entire process has nothing to do with Git repos and everything to do with identity and trust.

Once that mental model clicks, SSH stops feeling magical — and starts feeling solid.

If you run multiple services on one server, this pattern will serve you for years.

Happy hacking 🚀

DEV Community: cynthia wahome

The Supabase Gotchas Nobody Warns You About (Until You Hit Them)

The Symptom

Gotcha 1: The GRANT That Nobody Told You About

The Migration Template You Should Steal

The 60-Second Diagnostic

Gotcha 2: The Race Condition Nobody Mentions

Why This Happens With BaaS Platforms Specifically

The Pre-Launch Auth Checklist

Usipoziba Ufa, Utajenga Ukuta — On Technical Debt and the Discipline to Fix It

Context (Because You Deserve It)

1. Seal the Crack Before You Need a New Wall

2. Never Break the Architecture to Solve One Edge Case

3. Guard the Exit, Not the Entrance

4. The Bug That Only Existed in Production

5. Harden Your Logic Against Its Environment

What I Actually Came For

Cyfamod Technologies · GitHub

It Ran Fine in Production. Then I Wrote the Tests.

The Back Door That Was Literally Labelled

The Database That Only Looked Stable

The Vault and the Clerk

Tests Are Receipts, Not Optional

The Part Worth Keeping

The is-a.dev + Vercel Field Guide: Every Pitfall, Mapped

Step 0: Check Availability Before Anything Else

What You Need

Step 1: Fork, Clone, Branch

Step 2: Your Domain File

What the CI tests will catch here

Step 3: The Vercel Verification Pitfall 🚨

First — get your TXT token from Vercel

Where NOT to put the TXT record

Step 3b: The WWW Redirect Trap 🪤

Step 4: Submit the PR

Full Pitfall Reference

GitHub Pages? Same Pattern

Pre-Submit Checklist

After the Merge

TL;DR

this was a really fun drive 🚘 ...plus I totally love synthwave 😍 starting cursing here: https://sundaydevdrive.pilotronica.com contribute to the project here: https://github.com/georgekobaidze/sunday-dev-drive well done @Giorgi Kobaidze

Sunday DEV Drive: A Synthwave Driving Experience Through Your DEV Community Articles

Sunday DEV Drive

GitHub - georgekobaidze/sunday-dev-drive: A synthwave driving experience through your DEV Community articles · GitHub

Deep Dive: Resolving DNS Issues with GitHub and Understanding SSH vs HTTPS

The Problem: GitHub, You're Killing Me 😩

Step 1: Is GitHub Actually Down? 🌐

Step 2: Ping & DNS Lookup — Finding the Culprit 🕵️‍♂️

Ping test

DNS lookup

Step 3: Port Check — Confirm It's Not Just a General Outage 🔌

Step 4: Traceroute — Where Is the Connection Actually Dying? 🗺️

Step 5: Verify the Fix With a Known-Good IP 🧪

Step 6: Override DNS via /etc/hosts 🔧

Step 7: Switch Git Remote from HTTPS to SSH 🔑

Check your current remote:

Switch to SSH:

Verify:

Key Takeaways 💡

Full Troubleshooting Cheatsheet

Conclusion

I resonate so much with this

The Hardest Part of Being a Developer Isn’t Coding. It’s Disappearing Quietly.

NorthernDev ・ Feb 28

I Almost Filed a Bug Report. Then I Pressed Ctrl+P

The GitHub Rabbit Hole

scrollbars missing #2500

Cannot scroll on opencode when using iterm #6209

Description

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Wait, What Am I Even Running?

Then I Pressed Ctrl+P

What This Actually Was

The Real Takeaways

Quick Fix if You're Here for the Answer

Flutter Development Environment Setup (Apple Silicon macOS)

Step 6: Override DNS via `/etc/hosts` 🔧

Problem: `sdkmanager` exists but fails with JAVA_HOME error

Problem: `/usr/libexec/java_home` returns nothing

Problem: Chrome warning in `flutter doctor`

❌ `JAVA_HOME` invalid / sdkmanager fails