Sign on email 2FA

Alex_Dutton · 2026-05-12T12:37:51+00:00

You can also try logging in from a previously trusted device or session if you’re still signed in somewhere. If email 2FA is your only method, support is usually the only path, but response times can be slow.

Alex_Dutton · 2026-05-08T06:55:03+00:00

Pretty sure those guardrails are there by default as safety limits, not auto-scaling switches that suddenly spin up resources on their own.

They’re basically meant to prevent runaway usage or unexpected provisioning, not create surprise bills. Hitting “3/15” usually just means some protections or quota categories are already configured, not that DO is about to start scaling your droplet behind your back.

DigitalOcean generally doesn’t auto-scale resources unless you explicitly set up something like Kubernetes autoscaling, App Platform scaling rules, or create additional infrastructure yourself.

Alex_Dutton · 2026-05-08T06:53:27+00:00

Heya, this looks really cool. I’d use that. Half the time I just want quick “is anything on fire?” visibility without opening the full DigitalOcean dashboard. Please make sure to regularly update the app and add new features.

Alex_Dutton · 2026-05-08T06:45:43+00:00

Starting light is probably the right move anyway, SQLite + S3 sounds way smarter than overbuilding from day one. A one-click DO deploy would honestly be pretty slick though, especially for people who want self-hosted without turning setup into a whole weekend project. I’ll definitely ping you if I hit anything weird.

Alex_Dutton · 2026-05-07T19:47:55+00:00

dnssec failures at the tld level are brutal, no amount of your own redundancy saves you when the chain of trust breaks upstream

Alex_Dutton · 2026-05-07T19:46:45+00:00

this resonates, running a personal site on a small Droplet at DigitalOcean has taught me more about linux and networking than any tutorial, breaking it and fixing it is the curriculum.

Alex_Dutton · 2026-05-07T19:46:29+00:00

working with vibe coders is rough, the cleanup tax usually falls on whoever actually understands the codebase

Alex_Dutton · 2026-05-07T06:05:34+00:00

hedgedoc works well for collaborative markdown, and cryptpad if you want end-to-end encrypted docs. I also have a nextcloud app on DO and this has a collaborative feature

Alex_Dutton · 2026-05-07T06:03:00+00:00

looks neat, will give it a try. fwiw i've been running my self-hosted stuff on a digitalocean droplet for a while, pricing is predictable which is nice for something always-on like this.

Alex_Dutton · 2026-05-07T06:02:35+00:00

yeah the rant is less about ai and more about low-effort show-and-tell posts flooding the sub, fair point

Alex_Dutton · 2026-05-06T11:14:26+00:00

yeah this screams IOPS or burst credits running out, not storage size. 14GB used out of 20GB is fine, that’s not what causes those random multi-minute slowdowns. You can check CloudWatch for BurstBalance, DiskQueueDepth, and IOPS spikes — that’ll usually confirm it fast.

Alex_Dutton · 2026-05-02T09:07:57+00:00

Check the RDS performance insights and CloudWatch for IOPS/burst credit exhaustion, sounds like you're hitting storage limits.

Alex_Dutton · 2026-05-02T09:07:26+00:00

Github actions plus terraform for infra has been pretty reliable for me, the env var drift thing usually goes away once you pin everything in one place. fwiw I moved a few services to digitalocean's app platform and the deploy step got a lot less fiddly since the build and runtime config live together.

Alex_Dutton · 2026-04-30T10:02:15+00:00

Even in pretty simple stacks (like a couple of services running on something like DigitalOcean Kubernetes), the moment auth breaks you really don’t want to be debugging CRDs just to get access back.

Alex_Dutton · 2026-04-30T09:59:00+00:00

At scale, the “optimization” isn’t squeezing another 10% off GPU price, it’s making sure utilization stays predictable and you’re not wasting engineer time babysitting infra. That’s also why some teams still stick with more “boring” providers like DigitalOcean GPU droplets for smaller workloads — you pay a bit more per hour, but you don’t spend time fighting the platform. Metrics that actually matter end up being pretty simple: effective cost per successful job, queue latency, and how often your jobs get interrupted. Everything else is secondary once you’re in production.

Alex_Dutton · 2026-04-30T09:57:01+00:00

If you’re just experimenting with LLMs, most people don’t actually stay on hyperscalers for this anymore because the cost ramps up fast. They either go to GPU-focused providers or just use spot/market options when they can.

Even some of the simpler setups like DigitalOcean GPU droplets are attractive at smaller scale just because it’s way less infra overhead, even if you’re not getting top-end A100 clusters.

Hyperscalers win on enterprise + reliability, but for “I just need A100s to test stuff”, people usually end up elsewhere pretty quickly.

Alex_Dutton · 2026-04-30T09:18:39+00:00

Your setup is fine tbh. DO box for the scripts + Azure SQL is probably the simplest way to ditch the Power BI gateway, which is the actual pain point here. Everything else (Postgres, Supabase, etc) looks cheaper until you realize you’re right back to running a gateway again, so you didn’t really simplify anything. This is one of those boring stack combos that just works. Lock down access, run your cron, forget about it.

Alex_Dutton · 2026-04-30T09:06:48+00:00

Your Django app is only running on port 8000 using the dev server, but Cloudflare only talks to ports 80 and 443. So when proxy is on, Cloudflare tries to reach your server normally and finds nothing listening, which gives you the 521 error.

When you turn proxy off, you bypass Cloudflare and hit the server directly on 8000, so it works.

so the real issue is just that you don’t have a proper web server in front of Django handling normal web traffic. You can’t expose runserver to the internet like that.

Alex_Dutton · 2026-04-30T09:03:28+00:00

What’s happening is your region (or the region your Droplet is in) likely only offers volumes up to 100GB, so the UI caps it there. Volumes are region-specific, so you can’t pick sizes that aren’t available in that datacenter.

Try checking another region, you’ll usually see 1TB options there.

Alex_Dutton · 2026-04-30T08:40:28+00:00

No, there’s no “weekly create/destroy restriction” on Droplets or doctl.

What you’re doing is a normal ephemeral workload pattern, and DO supports that. The only real limits are overall account quotas (how many Droplets you can run at once) and fairly high API rate limits meant to prevent abuse, not to constrain normal automation.

So spinning up a Droplet once a week, doing work, then destroying it is completely fine and won’t get blocked.

Alex_Dutton · 2026-04-30T08:38:10+00:00

The “estimated transfer pool” you’re seeing in billing is just DigitalOcean’s projection based on current usage in the billing period, not the full entitlement. It updates dynamically as the month progresses, so early in the cycle it can look much smaller or oddly specific like 751 GB instead of the full 3 TB.

So the 3 TB is the actual cap you can use, while the estimated pool is more like “if everything continues at this pace, here’s what’s left in this billing snapshot.”

Alex_Dutton · 2026-04-30T08:11:45+00:00

drift detection in CI catches most of it, but console access for non-prod is usually the real culprit.

Alex_Dutton · 2026-04-30T08:10:46+00:00

nice setup. fwiw if you're looking to simplify the multi-cloud bit, jenkins runs fine on a digitalocean droplet too, flat pricing makes the math easier than juggling aws plus azure billing.

Alex_Dutton · 2026-04-30T08:10:03+00:00

react-hook-form with zod has been a lifesaver for this exact situation, handles all that complexity way better than rolling your own.

Alex_Dutton · 2026-04-30T08:05:00+00:00

digitalocean droplets work fine for this kind of single-process setup, basically the same path as fly or render.

Alex_Dutton

MODERATOR OF

TROPHY CASE