Worklog for task "Add minimal project management functionality"
Universal hosting and routing scheme for child projects confirmed
An important interim result has been achieved regarding minimal project management: a scheme has been experimentally confirmed in which the platform manages the project from the outside, while the project itself retains complete autonomy on the inside.
The child project successfully starts in an isolated Docker environment without publishing its own port on the host and becomes accessible via the platform's single common Traefik. The pilot haih-site correctly opens via its assigned hostname through the platform's common entry point.
What this provides
The platform does not need to know the internal stack of each project. Inside the project, there can be Node.js, PHP, databases, caches, its own reverse proxy, and any other services described by its Compose. The project independently determines its internal architecture and remains portable: its environment can be run independently, and Narasim adds an external management and publication layer.
This results in two levels of responsibility:
Internet / user / agent
↓
platform's common Traefik
↓
selected project
↓
project's internal proxy / Compose
↓
internal services
The common Traefik solves only the task of selecting the project by domain. Everything that happens inside the project remains its own responsibility. Thanks to this, adding a new technology stack does not require writing special installation and routing logic for each of its services within the platform.
Correct route isolation verified
Separately, an important false-positive scenario was eliminated: a request to a missing child project is no longer masked by the platform's main application. The main application is restricted to its own hostname, so an unknown or unavailable child route correctly results in a 404 instead of opening someone else's site.
This is important not only for UX, but also for future automated startup verification: the mere fact of receiving an HTTP response from the common proxy does not yet mean that the requested project is actually working.
Value for an agent-driven platform
The required boundary of a universal project runtime is practically confirmed. An agent can receive a task, prepare a project in a stack suitable for it, launch it as an independent system, and provide the user with a working address. Meanwhile, the platform can limit itself to general project lifecycle operations instead of knowing the details of every technology.
This creates the foundation for hosting multiple independent projects behind a single entry point without allocating a separate host port to each project and without the need to rebuild the common proxy to suit the internal structure of the application.
What we consider proven now
At the current stage, specifically the hosting and HTTP routing scheme has been confirmed:
- a child project is capable of operating as an independent Compose stack;
- the project's external container does not require a published host port;
- the common Traefik is capable of routing a request to the desired project by hostname;
- inside the project, there can exist its own proxy responsible for its services;
- the main site of the platform does not intercept missing child routes;
- adding such a project does not require the platform to know its internal technology stack.
We do not yet consider resolved the managed waiting for application readiness, the full API lifecycle, startup stage diagnostics, data saving/restoration, access permissions, and full isolation of untrusted code. Privileged DinD is convenient as a technical boundary for the experiment, but in itself is not a sufficient security model for running arbitrary untrusted code.
The main result of this stage: an architectural boundary has been found and practically tested that allows Narasim to manage independent projects as complete systems without turning the platform into a universal installer for all possible stacks.