# Hosting decision brief — custom apps alongside WordPress

Context to paste into a hosting-focused session. Written 2026-08-25 from a real,
running example so the requirements are measured rather than guessed.

---

## The decision

I host WordPress on Flywheel, Rocket.net and Cloudways. All three are
WordPress-centric or WordPress-only. I am now rebuilding several apps outside
WordPress and need somewhere for them. Two options I am weighing:

**A. A separate host just for custom apps.** Keep WordPress where it is, add
something like DigitalOcean purely for apps.

**B. One new environment that does both.** Stand up a server (DigitalOcean or
similar), host custom apps there, and migrate some of my Cloudways WordPress
sites into the same environment.

I want a recommendation between these, and if it is B, what the migration path
and the ongoing operational burden actually look like.

## Something I want checked before anything else

Cloudways is a managed layer that runs on top of DigitalOcean, Vultr, Linode and
AWS. If my Cloudways servers are already DigitalOcean-backed, then option B is
not really "migrate to DigitalOcean" — it is "drop the Cloudways management
layer and self-administer the same underlying infrastructure." That reframes the
question as: what am I actually paying Cloudways for, and am I prepared to take
that on myself? I would like this confirmed or corrected before comparing prices.

## The reference app (one of several; the most demanding)

A duty-free price comparison site. Live and in production use.

**Stack:** FastAPI (Python 3.12) serving both a JSON API and a built React SPA
from one process, PostgreSQL 16, both in Docker via docker compose. A reverse
proxy (currently Caddy) terminates TLS and provides certificates.

**Measured resource use, not estimates:**

| | |
|---|---|
| App container | 68 MB RAM, ~0% CPU idle |
| Postgres container | 40 MB RAM |
| Database on disk | 17 MB |
| Whole workspace including code and backups | 299 MB |
| Traffic | Very low. Read-heavy, no user accounts yet. |

It is small. Capacity is not the constraint; the operational shape is.

**The part that actually drives the hosting choice — background collection:**

- Nine external retailer sites are read on a schedule to gather prices.
- Each site publishes how fast it is willing to be read, and we go slower than
  that. Delays are 30 to 60 seconds *per request*, deliberately.
- So a collection run is a long-lived process that is mostly asleep. The longest
  single run so far was **59 minutes**, almost all of it waiting.
- A full sweep across all sources writes roughly 3,400 rows. Trivial data
  volume, long wall-clock time.
- Today these are triggered by hand. They need to move to a schedule (nightly
  for some sources, weekly for others), plus alerting when a run fails or
  returns far less than the previous run.

**Why this matters for platform choice:** platforms that bill by compute-time or
treat long-running background workers as a premium tier (Render, Railway, Fly
and similar) look like a poor fit for a process that sleeps for an hour by
design. A plain VM with cron seems the natural home. I would like that assumption
challenged if it is wrong.

**Outbound IP reputation — the risk I am most worried about.** This app makes
requests to retailer websites, several of which sit behind bot protection. It
currently runs from a server on an IP with a clean history. Datacenter ranges,
Hetzner especially and DigitalOcean to a lesser degree, are widely reported as
pre-blocked by Cloudflare-fronted sites because of abuse originating from them.
A migration could therefore silently break data collection in a way that looks
like the retailers changed something.

Questions: how real is this in practice in 2026, which providers have the
cleanest outbound reputation, and what is the right way to test it cheaply
before committing? Is a dedicated or bring-your-own IP worth paying for here?

To be explicit about conduct: this is polite, robots-respecting collection of
public prices. We never sign in, we honour every published crawl delay, and we
stop entirely when a site asks us to, which has already happened twice. I am not
looking to evade anything. I want an outbound IP that is not punished for other
people's behaviour.

## What I already run, and like

My own server hosts WordPress sites and custom apps side by side: one reverse
proxy in front, a small gateway service that manages containers, ports, DNS and
per-project permissions, each project isolated in its own directory with its own
container and database. It works well and I understand it.

So option B is essentially "put this pattern in the cloud." Which raises:

- Is it better to rebuild that arrangement myself on a plain VM, or adopt an
  existing self-hosted platform layer (Coolify, Dokku, CapRover) that does the
  same job?
- If a platform layer, which is the most credible in 2026 for running **both**
  Docker apps and WordPress, and what happens when the layer itself has a
  problem?

## Constraints and preferences

- I am a solo developer. Client sites are involved, so being personally on call
  for a WordPress outage at 2am is a genuine cost, not a theoretical one.
- I find Rocket.net clunky to use and am not planning to consolidate onto it,
  regardless of its performance.
- I would like to reduce the number of hosting relationships I maintain.
- Some of these apps belong to clients. One in particular may eventually need to
  live in the client's own account rather than mine, so portability and a clean
  handover matter more than lock-in-flavoured convenience.
- Budget is not the deciding factor at this scale, but I would rather not pay a
  premium for managed services I will not use.

## What I want out of the answer

1. A recommendation between A and B, with the reasoning.
2. If B: which provider, what size, and what the WordPress migration off
   Cloudways actually involves, including what I lose.
3. Whether a self-hosted platform layer is worth it or whether plain
   docker compose plus a reverse proxy is the better call at my scale.
4. A concrete answer on outbound IP reputation and how to test it first.
5. What the ongoing operational burden of option B looks like in hours per
   month, honestly stated, including backups, updates and security.
6. Where scheduled jobs and alerting should live in whichever option wins.