Workers

Availability

Workers is available to every project. On its first deployment, a project that uses one of the frameworks below runs as a Worker. A project that already runs as a container or a static site keeps its runtime; see Containers and static sites. If Eurobase pauses Workers, projects that already run on it keep serving their current deployment, and new Workers builds are refused until it resumes.

Supported frameworks

The version is the one your lockfile resolves. Eurobase never upgrades your framework: an older version stops the deployment and says which version you need. When your repository has no Wrangler config, the build runs framework setup, which adds the framework's adapter at a version Eurobase pins, with a warning when that version isn't reviewed for your framework version. Your repository isn't changed. A deployment can carry warnings, for example for a framework version that is past its end of life or has known vulnerabilities.

How the runtime is chosen

Eurobase picks the runtime from your repository on the project's first deployment and keeps it. A project goes to Workers when its package.json declares one of the frameworks above and it isn't a Node server. A Node server is a project that declares express, fastify, @nestjs/core, koa, @hapi/hapi, restify, @adonisjs/core or @feathersjs/feathers, or whose start command runs its own file, such as node server.js. A framework's own server start, such as next start or SvelteKit's node build, doesn't count.

The build then checks the repository for a supported Worker build. These projects build as containers instead:

• a framework that isn't in the table;
• more than one framework in the same root directory;
• a workspace (monorepo) root; set the project's root directory to the app instead;
• a Wrangler config with pages_build_output_dir;
• Hono without a Wrangler config;
• Node servers, and every project that isn't a Node project, including plain HTML sites without a package.json.

Later commits don't move a project to another runtime. If a commit would, the deployments page asks you to confirm with Switch runtime and deploy.

Build

The build installs exactly what your lockfile lists. Without a Wrangler config it runs framework setup and that setup's build command; with one, it runs build.command from your config, or else the framework's default. It then packages the Worker with wrangler deploy --dry-run. The project's Build and Start command settings aren't used for Workers. A build gets 4 vCPU, 6 GB of memory and 45 minutes; the source can be up to 512 MiB (1 GiB unpacked) and the build output up to 512 MiB.

Commit exactly one lockfile: package-lock.json or npm-shrinkwrap.json (lockfile version 2 or 3), pnpm-lock.yaml, yarn.lock (Yarn classic or Berry) or bun.lock. The package manager version comes from a committed Yarn release (yarnPath), else an exact packageManager field in package.json, else the default for the lockfile: npm 11.17.0, pnpm 11.27.0, Yarn 1.22.22 or 4.18.0. Bun always runs 1.4.2. A pnpm lockfile older than 9.0 needs a packageManager field.

A release must stay within these limits, or the build fails with the reason:

• Worker bundle: 10 MiB gzip-compressed and 25 MiB uncompressed, at most 256 modules.
• Static assets: at most 20,000 files of up to 25 MiB each.
• _headers and _redirects: up to 1 MiB each, 100 header rules, and 2,000 static plus 100 dynamic redirects.
• compatibility_date no later than the date Eurobase's workerd version supports, and no experimental or unsafe compatibility flags.

Before activation, Eurobase renders up to 16 concrete pages from the build output, including / and generated dynamic URLs when available. Next.js API routes and unresolved parameters are excluded. Checks have 45 seconds total, with up to 10 seconds per response and 2 MiB per HTML/React render. A 5xx, rendering error or incomplete render stops activation and shows the route and reason. The previous release keeps serving. A 401 login page or an API-only Worker's 404 is accepted. This is a bounded smoke check, not a check of every app state.

When a commit can’t deploy

For a Workers project, these stop the deployment with an explanation and the fix, and the current deployment keeps serving:

• a framework or Vite version below the minimum, or one the lockfile doesn't resolve (Vite 6.0 needs 6.1.0 or later);
• no lockfile, or more than one;
• bun.lockb: run bun install --save-text-lockfile and commit bun.lock;
• an npm lockfile version 1: run npm install --package-lock-only;
• a packageManager field that doesn't match the lockfile or isn't an exact version.

Variables and bindings

The project secrets bound to the app are available when the Worker runs, in env and, with Node.js compatibility on, in process.env, next to the vars from your Wrangler config. A secret must not share a name with a configured binding, including a var: a cold start is refused with 503 secret-binding-conflict. Rename the secret or binding before redeploying. Today secrets aren't available during the build. Saving a secret starts a new deployment of a live Worker using the existing release. The secret change stays saved even if activation fails; cold starts using the previous secret configuration can be refused until a new deployment succeeds.

The only bindings available are ASSETS and a service binding to the Worker itself, which OpenNext uses. A Wrangler config that declares KV, D1, R2, Durable Objects, queues or other services fails the build with unsupported_binding. Bindings a framework adapter adds on its own, such as Astro's sessions and images, exist but calls to them fail with 501. The Cache API accepts calls but stores nothing, so every lookup misses.

Runtime limits

A Free Worker instance has a 160 MiB memory limit and, after startup, at most half of one vCPU. Starter and Pro instances have a 256 MiB memory limit and at most one vCPU after startup. The resource class is selected from the organization's plan when a deployment's route is staged and stays with that route. Changing plan does not resize an existing route or its running instance; a new deployment selects the current plan's class.

The following limits apply to both resource classes.

Monthly CPU budget

Workers CPU is measured across all projects in your organization, in CPU milliseconds: Free includes 3,000,000 ms (50 minutes), Starter 30,000,000 ms (500 minutes), and Pro 100,000,000 ms (1,666⅔ minutes) per calendar month. The budget resets at 00:00 UTC on the first day of each month. This measures CPU consumed after startup, including background work, rather than request duration or time spent waiting for I/O. Startup CPU is excluded.

Workers and Functions share the organization's execution admission: reaching the Workers CPU budget or either Function monthly allowance blocks new executions of both with 429 quota-blocked. Static assets served without Worker execution remain available. For example, after an organization uses its 50 Free CPU minutes, a Worker API route and a Function are blocked while an asset-only image can still be served.

Check your organization's Usage page. Wait for the monthly reset, or upgrade Free or Starter to a plan whose allowance covers your usage; Pro must wait for the reset. An upgrade changes the allowance, without clearing CPU already used this month. A short retry does not recover an exhausted budget. See Plans and limits for all monthly allowances.

Errors your visitors can see

When Eurobase answers instead of your Worker, the response carries an X-Eurobase-Gateway-Error header with the reason. A browser opening a page sees an error page; other requests get JSON with error, reason, requestId and retryable (true for 5xx).

Requests and logs

On a Workers project's deployments page, Requests and logs opens the Worker page with the last 24 hours. Requests lists each request with its status, outcome, duration and whether it was a cold start. Logs shows your Worker's console output, uncaught errors and platform events such as a stop. Each deployment can log about 100 lines per second, with bursts up to 1,000; lines over that rate are dropped and counted as Lines dropped. A line longer than 8 KiB is cut at 8 KiB.

Headers and paths

• Your Worker receives X-Forwarded-Proto: https and X-Forwarded-Host, and, when Eurobase knows the visitor's IP address, one X-Forwarded-For and one CF-Connecting-IP header with it. Incoming X-Forwarded-*, Forwarded, CF-*, Proxy-*, X-Real-IP, True-Client-IP and X-Eurobase-* headers are removed first.
• Paths under /__eurobase/ are reserved for Eurobase and never reach your Worker.
• Cookies work, with rules that keep other apps on eurobase.dev from forging them; see Cookies in your app.

Runtime code generation

eval() and new Function() during a request are not supported on Workers for now. A typical error is Code generation from strings disallowed.

This affects Next.js MDX libraries that evaluate compiled strings while rendering, such as Pliny/Contentlayer's getMDXComponent. Compile MDX to importable modules at build time, or use a library that does. Compiling MDX into a string that is evaluated on each request does not avoid the limit.

Build logs warn about possible runtime code generation and name the bundled module. A warning alone does not stop a deployment; the candidate render check does.