I am developing a Next.js App Builder app locally, then uploading its source to a self-hosted Teable instance. I would like to understand the supported way to keep the Node.js version consistent across local development, preview, build, and the published app.
Observed behavior
In a recorded probe on September 23, 2026, the sandbox initially provided Node.js 24.19.0, while the published app reported Node.js 22.23.1.
We then explicitly tested this package.json configuration:
{
"engines": { "node": "26.9.0" },
"pnpm": {
"executionEnv": { "nodeVersion": "26.9.0" }
}
}
With Next.js 16.2.9, the results were:
| Measurement | Node.js version |
|---|---|
Preview: server-side process.version |
26.9.0 |
Remote build: process.version recorded during the build |
26.9.0 |
Published app: server-side process.version |
22.23.1 |
The published app returned the new deployment marker, so this was not simply an old deployment. We distinguished the build-time JSON file from the live server response: a file generated during the build does not prove which Node version is serving the published app.
These are results from that test, not a claim that every Teable deployment currently uses those versions. We subsequently pinned local development and preview/build to 22.23.1 to match that production runtime. Node 26 was a probe; the main question is version consistency, not a requirement to support Node 26.
What we found while investigating
The public deployment configuration separates SANDBOX_OPENSANDBOX_IMAGE from APP_RUNTIME_DEFAULT_IMAGE:
Teable deployment configuration
We also inspected the published image ghcr.io/teableio/teable-app-runtime:20260919T055651Z. Its image configuration declares NODE_VERSION=22.23.2. This is a separate inspection of an official image, not the version measured in our September 23 deployment.
The entrypoint in that image defaults to node server.js when a standalone server.js exists, and otherwise to pnpm start, unless APP_START_COMMAND overrides it. That appears to explain why pnpm.executionEnv.nodeVersion affects preview/build but does not select the Node executable for the standalone production path.
The pnpm 9 documentation says this setting applies to pnpm run and pnpm node:
pnpm 9 runtime configuration
Investigation conclusion and requested version alignment
The evidence points to two independently selected Node runtimes: preview/build can use the Node version selected by pnpm inside the sandbox, while the published standalone app starts with the Node executable supplied by the separate App Runtime image. Updating the app’s package.json therefore does not, by itself, align the production runtime.
Please align the actual Node.js versions used by App Builder preview, remote build, and published apps. The same app deployment should use the same supported Node version, ideally pinned to the same exact major.minor.patch version across all three stages.
Specifically, the requested behavior is:
- The default sandbox preview/build runtime and production App Runtime should have a coordinated Node version, with a documented version that developers can also use locally.
- If per-app Node selection is supported, it should apply consistently to preview, build, and production. An unsupported production version should produce an explicit validation error instead of successfully building with one version and silently running with another.
- Both the build-time Node version and the live production Node version should be visible. A generated build metadata file alone is insufficient.
For example, in the tested deployment whose production runtime was 22.23.1, local development, preview, and remote build should also run on 22.23.1. If the platform moves production to a supported Node 24 release, the other stages should move to the same release. This request is about aligning versions, not forcing Node 26 or assuming that every current deployment runs our historical versions.
The practical concern is that version-specific Node APIs or dependencies may work in preview and pass the build, but behave differently after publication. App developers without infrastructure-admin access cannot reliably resolve that mismatch by changing package.json alone.
Questions
- Can Teable align these Node versions by default, and is the current mismatch expected or something that should be fixed?
- What is the supported way to choose or discover the production Node version? Is there a per-app option, or must an administrator change the runtime image?
- Until the versions are aligned by the platform, is pinning local development and preview/build to the observed production version the recommended approach?
Thank you for confirming the supported configuration and the recommended way to keep the versions aligned.