Developers/Scaling

Scaling

An app can run as several copies on several servers. You can do it by hand on servers you already have (multi-server), or let Hostwolf add and remove servers as CPU load changes (autoscaling). Either way, keep state out of the app's own disk: put data in a managed database, which every copy reaches.

Multi-server#

Add another of your app servers to an app, then deploy. Hostwolf builds the image once, starts a copy on every server, and the app's main (primary) server spreads requests over all healthy copies. If a copy stops, requests go to the others.

# The other server's destination (a Docker network on that server)
DEST=$(hw $API/servers/$OTHER_SERVER/destinations | jq -r '.[0].uuid')

hw -X POST $API/applications/$APP/destinations -d "{\"destination_uuid\": \"$DEST\"}"
hw -X POST $API/applications/$APP/start

hw $API/applications/$APP/destinations | jq   # primary + copies

$OTHER_SERVER is a server_uuid from GET /hostwolf/servers. To stop running a copy on a server:

hw -X DELETE $API/applications/$APP/destinations/$DEST

• Every server needs to be one of your Hostwolf app servers. The primary can't be removed; it is where the app is built.
• During a deploy each server restarts its copy, and requests go to the copies that are up in the meantime.
• Volumes are per server: each copy has its own. Shared data belongs in a managed database.
• In the SDK: applications.addServer(appUuid, serverUuid); in MCP: add_app_server.

Autoscaling#

Autoscaling adds an app server when the app's average CPU stays high, and removes it when load drops. New servers are placed in the city that sends the most traffic, or in the cities you allow. Each added server is the same size as the app's main server.

hw $API/applications/$APP/autoscaling | jq

{
  "configured": false,
  "blocker": null,
  "policy": {
    "enabled": false, "min_copies": 1, "max_copies": 2, "monthly_cap_usd": 50,
    "allowed_cities": [], "scale_up_cpu": 60, "scale_up_minutes": 2,
    "scale_down_cpu": 15, "scale_down_minutes": 5, "cooldown_minutes": 3
  },
  "cities": [{"id": "vultr:fra", "city": "Frankfurt", "country": "DE", "monthly_price": 18.79, "hourly_price": 0.0257}],
  "status": null
}

Turn it on with PUT. Fields you leave out keep their value:

hw -X PUT $API/applications/$APP/autoscaling -d '{"enabled": true, "max_copies": 4, "monthly_cap_usd": 40}'

cities in the same answer lists the region ids allowed_cities accepts for this app, cheapest first, with the hourly price of one server there. GET /hostwolf/regions?size=s lists every city with the price of each size; autoscaling: true marks the cities autoscaling can use.

Billing: autoscaled servers cost the regular price by the hour (monthly price ÷ 730), added to your next server invoice. Once this month's autoscaled hours reach monthly_cap_usd, no more servers are added and team admins get an email. status.spend_usd shows this month's spend so far, and status.copies lists the running copies with their city and CPU.

When it can't be turned on, blocker (and the 409 answer to PUT) says why:

• the app's main server isn't one of your Hostwolf app servers, or isn't running;
• the app has no port set (ports_exposes);
• your team has no active server subscription to add the hours to.

A new server takes about four minutes to join, so set min_copies ahead of a launch you know about.

Push deploys with several copies#

Push deploys and CI deploys work the same with several copies: one build, then every copy is updated, including servers that autoscaling added.