Use Node as the build tool
StaticX hosts the static output that Node tooling generates, not the Node process itself.
Framework hosting
Host static assets produced by Node.js tooling. StaticX does not run long-lived Node servers.
StaticX hosts the static output that Node tooling generates, not the Node process itself.
Upload dist, build, public, out, or another browser-ready folder, not node_modules or server internals.
If your static frontend calls APIs, host those APIs on a runtime service and keep StaticX focused on the site.
Use npm scripts to build files, then deploy only the public browser assets to StaticX.
Use the project script that writes HTML, CSS, JavaScript, and assets into a static output folder.
Exclude package caches, private config, server code, and files not meant for visitors.
Upload the output root and publish a new StaticX version for history and rollback.
Many static sites use Node.js only during development: bundling, minifying, generating HTML, or compiling assets.
StaticX fits that model. It receives the generated files and serves them as immutable releases while any server-side API remains outside the static hosting layer.
StaticX does not run Express servers, queues, scheduled jobs, or WebSocket services.
Dependencies are build inputs, not public website assets.
Browser calls should target external API endpoints configured safely at build time.
Short, practical answers for using this page safely.
No. StaticX hosts static files generated by Node tooling. Runtime Node apps need another host.
Upload the folder your build script creates for browser assets, commonly dist, build, public, out, or _site.
Yes. Run the build script, then call the StaticX CLI or API with a scoped token.
Yes, when the generated HTML includes StaticX-compatible form markup.