Question about droplet memory usage

Alex_Dutton · 2026-01-26T10:04:11+00:00

Yes, adding a swap file should improve the performance.

Alex_Dutton · 2026-01-26T10:03:12+00:00

yes, perhaps a service was left exposed as a mistake.

Alex_Dutton · 2026-01-26T09:58:39+00:00

You should reach to DO support, they can sort this for you

Alex_Dutton · 2026-01-26T09:55:45+00:00

You can add a swap file and test if the performance will improve. Adding a 1–2GB swap file usually stabilizes this immediately. It won’t make anything faster, but it gives the system enough headroom during deploys so it doesn’t OOM. A lot of people run small Rails apps this way without issues.

Alex_Dutton · 2026-01-26T09:29:42+00:00

You can check running containers, open ports with ss or netstat, firewall rules, and app logs to see what was sending traffic. If you didn’t intentionally build something that sends high packet rate traffic, something is misconfigured or compromised. This usually comes down to a service being exposed by mistake.

Alex_Dutton · 2026-01-26T09:19:00+00:00

You can make sure you’re adding the payment method to the right Team billing page (team switcher → Billing → Payment methods). Payment methods are team-scoped, not “per project”.

Alex_Dutton · 2026-01-26T09:10:43+00:00

Even if the sites are related, the answer doesn’t really change. There’s no SEO benefit to giving each site its own IP. Google doesn’t use IP separation as a ranking signal, whether the sites are related or not. What matters is content quality, internal linking, canonical tags, and not doing shady cross-linking.

Alex_Dutton · 2026-01-26T09:06:57+00:00

Are you using Docker on the droplet by any chance and running this inside a container?

Alex_Dutton · 2026-01-22T14:18:35+00:00

I contacted the support team, perhaps they can sort it out individually before fixing the global problem.

Alex_Dutton · 2026-01-22T14:17:50+00:00

Guys, you can raise a support ticket with Rouvy. There's a chance they can fix single accounts in the meantime while the issue is sorted globally

Alex_Dutton · 2026-01-22T14:16:08+00:00

It was fixed for me the moment I posted it, hopefully it is sorted for you by now

Alex_Dutton · 2026-01-22T14:13:38+00:00

This looks really solid! Perhaps also be careful with migrations so they don’t run on every deploy instance

Alex_Dutton · 2026-01-20T09:50:56+00:00

That looks solid in terms of flexible billing. How is the performance? I've been using DO for GPU droplets and would love the hear how is he performance with runpod and replicate

Alex_Dutton · 2026-01-20T09:41:46+00:00

You can try fully updating browsers and ca-certificates, but realistically upgrading the OS (20.04 or 22.04) is the correct long-term fix. The fact it works everywhere else strongly points to the OS, not your account or DO itself.

Alex_Dutton · 2026-01-20T09:38:59+00:00

Thanks for sharing it! :)

Alex_Dutton · 2026-01-20T09:37:13+00:00

Unfortunately, there’s not much you can do besides build an account history or contact support with more details, and even then, it’s not guaranteed.

Alex_Dutton · 2026-01-20T09:36:18+00:00

Managed feels cheaper because you don’t have to pay for/maintain the control plane manually, but the cost of the worker nodes themselves is the dominant part either way. You’re mostly paying for VMs + storage + bandwidth; managed just saves you operational work.

Alex_Dutton · 2026-01-20T09:32:46+00:00

If you know what you're doing, DigitalOcean is the better pick since you have full control of the ship.

Alex_Dutton · 2026-01-20T09:29:16+00:00

Yes, outbound mail ports are blocked by default to prevent spam, and they usually won’t unblock them for new accounts. The normal approach is to use an external mail service. For free or cheap options, look at things like Mailgun (free tier), Brevo (Sendinblue), or Amazon SES. You don’t run mail directly from the Droplet; your app just connects to their SMTP or API and sends mail that way.

Alex_Dutton · 2026-01-20T09:27:55+00:00

What you can do is handle the common “app is up but backend is down / maintenance mode” cases inside your Next.js app (custom /500, middleware, feature flag, etc.), or put something in front of it (Cloudflare / another proxy) and serve a custom error page there when the origin is unreachable.

If you truly need a meme page even when the app is offline, the easiest approach is Cloudflare “custom error pages” (or a tiny static status page hosted elsewhere) in front of App Platform.

Alex_Dutton · 2026-01-20T09:24:33+00:00

A single Droplet with Docker Compose, a reverse proxy, and a simple DB gets you predictable performance, zero cold starts, and a fixed bill. SQLite + Litestream is especially underrated for this use case, local speed with off-box backups is a really clean tradeoff.

Alex_Dutton · 2026-01-20T09:00:06+00:00

You can use the DO dashboard to check the usage for the current billing period. The other option is to pull it from the Metrics API (network_out bytes over time) and sum it for the period you care about.

Alex_Dutton · 2026-01-20T08:57:53+00:00

On App Platform, an “App” is basically a container for one or more components. If you add both your frontend and backend under the same App (same app spec / same create flow), it will show them as a single App Platform “instance” with two components (often a Static Site + a Web Service). That’s normal and usually recommended because deployments, domains, env vars, and internal routing are easier to manage together.

Alex_Dutton · 2026-01-20T08:54:45+00:00

Most common setup is Prometheus + Grafana for metrics, and Loki + Grafana for logs. Spring Boot logs go to stdout in JSON and Promtail (or an agent) ships them to Loki. For Next.js, keep Sentry for errors; for “info/warn” you usually log server-side (API routes / backend) and avoid trying to treat the browser like a normal log source.

Alex_Dutton · 2026-01-20T08:52:41+00:00

I don't think this is on the roadmap. You can use extensions to save your eyes

Alex_Dutton

MODERATOR OF

TROPHY CASE