Engineering
Publish a custom stack with a reproducible launch setup
Use verified build and startup commands to publish a custom app and leave instructions useful to another host.
A project can contain JavaScript without being a Node server. A monorepo can contain several apps with different start commands. Supporting those projects requires a publisher to understand how the specific application builds and starts, then verify that setup.
Make the launch setup explicit
Rigless's hosted publishing flow uses five pieces of information: the project root, an optional build command, the production start command, the listening port, and the health path. These describe what to run and what an available application should answer.
Suppose a repository contains a frontend under apps/site and a separate utility under tools. Running a command from the repository root may start the wrong process or fail to find its dependencies. Choosing the correct project directory is part of preparing the release.
The same reasoning applies to ports and health checks. A process that listens only on localhost may work in a terminal check while remaining unreachable through the preview. A health path that always errors cannot establish readiness.
Verify the commands before publishing
Ask the agent to inspect the project and verify its production setup. The publishing flow can prepare missing launch configuration and shows the proposed details for review. If they are wrong, return to the project, explain the required behavior, and let the agent correct and verify the setup.
A useful preparation result names the command it ran, shows the application responding, and identifies missing production values. Development previews and production commands can differ, so check both.
The publishing guide walks through that process and the separate Free static-site path. Free Browser workspaces do not execute a custom build or server command.
Treat Docker as a reproducible recipe
A Dockerfile can document dependencies and startup for a custom runtime. It still needs a working build, an accessible port, suitable resource requirements, and a plan for application data.
An image cached in the development workspace is not itself a release configuration. The production setup must account for rebuilding or loading the image where the release runs. Multi-service applications need their dependencies and lifecycle verified as well. Docker and custom runtimes provides a small check and explains this boundary.
Leave instructions useful to the next host
Keep the runtime version, dependency files, launch commands, and configuration names with the source. Record data migration requirements separately. Those details let you diagnose a Rigless release and prepare the same application for another environment.
When publishing fails, use the stage and logs to choose the next action: correct the build, fix startup, provide missing values, or investigate the health response. A reproducible launch setup makes each of those failures more specific and the source easier to take with you.