Compute specifications

A site has one compute setting: its server specification. The same size applies while dependencies install and your storefront builds, and while the site serves traffic including server-side rendering. There is no separate build size to tune independently of the runtime size.

Alongside it sits the build runtime — which runtime the build executes on — and the request timeout. Those are three distinct fields, and only the first is about how much machine you get.

Setting it

The specification is a property of the site, so it applies from the next deployment:

revenexx sites update --site-id <SITE_ID> --specification s-4vcpu-8gb

In Cockpit, it is the Server specification field in the site's settings, under Experience Studio → Sites. The same screen carries Build runtime, Timeout (seconds), and the build commands — see Build configuration.

The sizes

Sizes are named s-<vcpu>vcpu-<memory>. Cockpit's picker currently offers seven, from half a vCPU with 512 MB up to four vCPUs with 8 GB:

curl -s https://api.revenexx.com/v1/sites/specifications \
  -H 'X-Revenexx-Tenant: <tenant-slug>' \
  -H 'X-Revenexx-Api-Key: <api-key>'

There is no tier that unlocks a bigger machine. What the list offers, it offers to every caller — there is no plan model gating compute and no upgrade path to buy your way to more vCPUs. The ceiling is the platform instance's own CPU and memory limit, which is why the API's list is the authoritative one for your environment.

The build runtime is a separate field

The specification says how much machine; the build runtime says what executes the build. Four values:

revenexx sites update --site-id <SITE_ID> --build-runtime node-24

Match it to what your project actually needs. A theme whose toolchain requires a newer Node will fail on an older runtime in a way that looks like a dependency problem.

When a build runs out of memory

Raising the specification is the usual fix for a theme whose build runs out of memory. A large block library — the reference theme's bundles plus your own — produces a lot of modules to compile, and the default heap can be too small.

Two knobs, and they are independent:

# 1. More machine
revenexx sites update --site-id <SITE_ID> --specification s-4vcpu-8gb

{
  "scripts": {
    "build": "NODE_OPTIONS=--max-old-space-size=3072 nuxt build"
  }
}

The second matters more often than people expect: Node will not use memory the machine has unless its heap limit allows it, so a bigger specification with an unchanged heap limit fails exactly the same way. If a build OOMs, raise both.

Because one specification covers build and runtime, raising it for a build also raises what the running site gets. That is usually fine — but it is the reason to fix a genuinely slow page by moving work off the render path rather than by resizing.

What it means for a running site

• A server-rendered storefront does real work per request — fetching, rendering, hydrating markup. It should not be on the smallest size.
• A static site executes nothing per request, so the size barely matters. Files are served from the edge.
• Check the request duration in the logs before resizing. A slow page is far more often a slow upstream call on the render path than an undersized machine, and the fix for that is deferring the call, not buying vCPUs. See Logs.

The site's request timeout — up to 30 seconds — is its own setting. See Build configuration.

What the runtime tells your code

The active specification is available to a running site as environment variables, so a health endpoint can report what it is running on:

Full list: Environment variables.

Related

• Build configuration — the commands, output directory, build runtime and timeout
• Environment variables — what a deployed site receives
• Deployments — statuses, build logs, and retrying a failed build
• Logs — request duration, before you resize anything