Mobile App Backend Hosting: How to Run Your API Server Without Regrets

A mobile app backend needs five things: an API server, a database, file storage, background workers for push notifications and slow jobs, and an authentication layer. For most apps before they reach serious scale, all five fit comfortably on one virtual server with dedicated CPU and RAM, as long as you keep backups off that server and know which part you will move out first. Below: what to run, how to size it, where to host it for users in Egypt, and how to grow without a rewrite.

What a mobile backend actually does

The app on the phone is a client. Everything that must be shared, trusted, or kept after the app is deleted lives on your backend. In practice that means:

• API server: the HTTP service the app talks to (Node.js, Django, Laravel, Go, .NET). It validates input, applies business rules and returns JSON.

• Database: usually PostgreSQL or MySQL for users, orders and anything relational. Add Redis for sessions, caching and rate-limit counters.

• File storage: profile photos, receipts, voice notes. Store files on disk or in S3-compatible object storage and keep only the path in the database.

• Workers and queues: sending push notifications through Firebase Cloud Messaging or Apple Push Notification service, resizing images, sending emails and SMS. These run outside the request so the app never waits on them.

• Auth: login, short-lived access tokens, refresh tokens, password reset and, if you need it, OTP by SMS.

Skip the worker layer and you feel it first: a signup that also sends an email and a push can take seconds on a slow third-party call. Queue that work and the response returns in milliseconds.

Backend-as-a-Service or your own server?

Backend-as-a-Service (BaaS) platforms give you a database, auth and storage through an SDK. Fine for a prototype; the trade-offs show up later:

• Speed to start: BaaS wins. You can have login and a database in an afternoon.

• Cost at growth: BaaS pricing usually scales with reads, writes, bandwidth or active users, so the bill grows with success and is hard to predict. A server has a fixed monthly price.

• Control: on your own server you choose the database engine, extensions and libraries. On BaaS you work inside its rules.

• Data location: with your own server you pick the country. This matters for regulated data and for latency.

• Lock-in: moving off a BaaS often means rewriting the data layer in the app itself, and old app versions stay on users' phones for months.

A sensible rule: if your app is a test of an idea, BaaS is fine. If you already have paying users or a business behind the app, run your own API from day one. Then you can change everything behind that API without shipping a new app version.

A starting architecture on one server

One server runs the whole stack cleanly if every piece has a clear boundary:

1. Nginx on ports 80 and 443 terminates TLS and proxies to your API on a local port.

2. The API runs as a systemd service, under PM2 for Node.js, or in a container. It listens only on 127.0.0.1.

3. PostgreSQL and Redis listen only on localhost. Never open port 5432 or 6379 to the internet.

4. A worker process reads jobs from Redis and calls push, email and SMS providers.

5. Uploads go to a dedicated directory outside the code folder, or to object storage.

If you write Node.js, our guide to running Node.js on a VPS with PM2 and Nginx walks through the process manager and reverse proxy setup. If you prefer containers, the Docker Compose production checklist covers restart policies, volumes and log rotation, which are the details that break first.

Mobile traffic has one quirk worth handling at the proxy. Many users on Egyptian mobile networks reach you through carrier-grade NAT, so hundreds of phones can share one public IP. Rate limits per IP must be generous, and stricter limits belong on sensitive endpoints such as login and OTP:

limit_req_zone $binary_remote_addr zone=auth:10m rate=5r/s;

server {
    server_name api.example.com;
    location /auth/ {
        limit_req zone=auth burst=20 nodelay;
        proxy_pass http://127.0.0.1:3000;
    }
    location / {
        proxy_pass http://127.0.0.1:3000;
    }
}

Replace api.example.com with your own subdomain. Combine IP limits with per-account limits inside the API, which are fairer for users behind shared IPs.

Sizing: rules of thumb that hold up

Exact numbers depend on your code, but these starting points rarely mislead:

• Launch: 4 vCPU and 8 GB RAM run a typical JSON API, PostgreSQL, Redis and a worker for an app in its first months.

• Memory split: give PostgreSQL around 25% of RAM for shared_buffers, leave room for the API processes, and keep at least 20% free for the operating system's file cache.

• Headroom: if CPU stays above 70% at your daily peak, or p95 response time keeps climbing, upgrade before a campaign or a release, not during it.

• Disk: NVMe matters more for the database than for anything else. Plan storage for the database, its logs, and at least two local dump files.

• Dedicated vCPU: an API that answers in 40 ms on a quiet server and 400 ms when neighbours are busy is hard to debug. Dedicated cores remove that variable.

IM HOST Cloud VPS plans with dedicated vCPU, RAM and NVMe come in 8, 16, 32 and 64 GB RAM, and you can move between plans as the app grows. That maps well onto the launch-then-grow pattern above.

When to move the database to its own server

Do not split early; two servers mean double the updates and monitoring. Split when you see one of these signals:

• The database and the API compete for RAM and the database cache hit ratio drops.

• Background jobs such as reports or exports slow down the live API.

• You need to scale the API to two or more servers, which requires a shared database anyway.

• Restoring the database must be possible without touching the application server.

Latency and server location for users in Egypt

A mobile app makes many small requests. On a phone network, each round trip already carries radio and carrier delay before it reaches your server, so the distance to the data center adds up quickly when one screen needs five API calls. Three practical rules:

• Host close to most of your users. For an Egyptian audience that means Cairo or a nearby European location. IM HOST runs data centers in Cairo, London, Berlin, Warsaw and New York; services are available across our locations subject to stock, and we confirm your location before activation.

• Reduce round trips. Design endpoints that return what a screen needs in one call, enable HTTP keep-alive and gzip or Brotli compression.

• Measure from a phone, not your office fibre. Test the app over 4G with the API logs open and compare timings.

You can check total response time from any machine with curl:

curl -s -o /dev/null -w "connect: %{time_connect}  ttfb: %{time_starttransfer}  total: %{time_total}\n" https://api.example.com/health

Backups and monitoring

Server-level backups protect you from losing the machine. They do not give you point-in-time recovery of a busy database. Take your own logical dumps and copy them off the server. A minimal nightly job, added with sudo crontab -u postgres -e:

0 3 * * * pg_dump -Fc appdb > /var/lib/postgresql/backups/appdb-$(date +\%F).dump

Create the backups folder first, then sync it to storage in another location and delete files older than your retention window. Test a restore with pg_restore into a scratch database at least once a month. A backup you have never restored is a guess.

For monitoring, start with three things: an external uptime check on a /health endpoint that also queries the database, alerts on disk usage above 80%, and error-rate tracking in your API logs.

The scaling path

1. Vertical: move to a larger plan. This is the cheapest engineering time you will ever buy.

2. Split the database: one server for the API and workers, one for PostgreSQL.

3. Horizontal API: two or more stateless API servers behind a load balancer. Sessions and uploads must not live on local disk by this point.

4. Dedicated hardware: for a large, steady database, a dedicated server gives predictable disk and CPU.

If you are unsure which server class fits each stage, compare them in Cloud VPS vs VPS: what actually differs. If your app is part of a subscription product, the SaaS infrastructure guide for the first 12 months covers staging, tenant isolation and restore drills.

Mistakes that cost the most

• Shipping API keys or database credentials inside the app binary. Anything in the app can be extracted. Secrets stay on the server.

• Hardcoding the server IP in the app. Use a hostname such as api.example.com so you can move servers by changing DNS.

• No API versioning. Old app versions live for months. Prefix routes with /v1/ from the start.

• Storing backups only on the same server.

Frequently asked questions

Can I host a mobile app backend on shared hosting?

For a simple PHP API with low traffic it can work, but most mobile backends need long-running workers, Redis, WebSockets or custom ports. Those need root access on a VPS.

How much RAM does a mobile app backend need?

As a rule of thumb, 8 GB RAM covers an API, PostgreSQL, Redis and a worker at launch. Watch memory at peak and upgrade when free memory stays under 20%.

Should the API and database be on the same server?

At the start, yes, with the database listening only on localhost. Split them when they compete for resources or when you need more than one API server.

Where should I host an API for users in Egypt?

As close to them as possible. Cairo keeps network distance short; nearby European locations are a reasonable alternative. Always test from a phone on a mobile network.

If you are ready to run your own API, start with a Cloud VPS with dedicated resources and automatic backups and grow between plans as your users do. Our engineers are available 24/7 if you want a second opinion on the setup.