This website is meant to be directly handed to Nolan as a working technical brief. It combines the current verified production state, the wider project ecosystem, the AI and GPU direction, the current constraints around Hermetica and Quant EVA, and a staged migration model for a cleaner Alibaba Cloud future.
The stack currently spans a live GCP web host, a Cloud Run multi-service trading platform, a separate protected KunstvanVB AI VM, a large private Hermetica family on Hostkey, image-generation infrastructure linked to Hephaistos / ComfyUI, and external burst-compute compute routes such as Kaggle. The right Alibaba strategy is not one giant all-in-one box, but one coordinated business landscape with clearly separated runtime roles.
PixelPiraterij production currently runs on a single Google Compute Engine VM with Coolify, Traefik, Directus, PostgreSQL and Redis.
Quant EVA is documented as a Cloud Run multi-service stack, not as a simple single VPS deployment.
Recommended target: one web/core host, one GPU/AI host, and later an optional private internal control host.
Build, validate, switch origin last, then only decommission old infrastructure after stable proof.
The most important distinction in this handover is between what is already hard-verified, what is strongly supported by local documentation, and what still needs live origin-level confirmation.
| Layer | Verified Today | Meaning | Status |
|---|---|---|---|
| PixelPiraterij production | Runs on GCP VM pixelpiraterij-vps in europe-west4-a, type e2-standard-2, 2 vCPU / 8 GB RAM / 30 GB pd-balanced, public IP 34.12.130.53. |
Main live web/business hosting node with Coolify, Traefik, Directus, PostgreSQL and Redis. | Hard Verified |
| Quant EVA | Locally documented as Cloud Run stack in project quant-eva with services quant-eva-backend, quant-eva-frontend, quant-eva-hmm, quant-crypto-frontend, lijfstats-frontend. |
This is already a split service architecture and should not be treated as a single website migration. | Hard Verified |
| KunstvanVB AI VM | Protected local documentation explicitly references GCP project project-d4314e7d-c0fd-4587-acc with VM kunstvanvb-ai-vps in europe-west4-a, and the project also contains the attached disk kunstvanvb-ai-vps as a live GCP resource. |
Separate AI/business runtime is documented and tied to real GCP infrastructure, even though this session did not fully inspect every in-guest process. | GCP Confirmed + Protected |
| Hermetica.cloud | Main domain responds behind Cloudflare and exposes an Express-based app. Live Hostkey files show the Hermetica private stack with reverse proxies and service routes for commandcenter, chat, workflow, memory, servicecenter and related lanes. |
Hermetica is not a small side surface here. It is a large private Hostkey stack with multiple protected services behind the public edge. | Large Hostkey Stack Confirmed |
| NotebookOS | notebookos.hermetica.cloud exists, is Access-protected, appears in local monitoring collector code, and has a concrete codebase with Hephaistos and Kaggle router/service references. |
NotebookOS belongs to the Hermetica runtime picture and was owner-confirmed as recently moved into the Hostkey stack, which also explains the Kaggle tie-in. | Hostkey Runtime Confirmed |
| Kaggle path | Kaggle is wired into NotebookOS and Hermetica render flows through runtime code, queue folders, dispatch endpoints and environment settings such as KAGGLE_CONFIG_PATH=/root/.kaggle/kaggle.json and KAGGLE_NOTEBOOK_ACCELERATOR=gpu-t4x2. |
Kaggle is the burst-compute lane inside the bigger Hermetica stack, especially for NotebookOS render jobs. The only open detail is the current remote session state. | Burst Compute Confirmed |
| Hephaistos / GPU path | ComfyUI workflows, cloud image pipelines and the alias hephaistos-wake are present in local materials, GCP directly confirms disk hephaistos-comfyui-80 in europe-west4-b, and owner confirmation identifies the runtime as an on-demand L4 24 GB GPU lane kept idle when unused. |
The GPU/image-generation path is real, disk-backed and intentionally cost-controlled. It is meant to stay idle or off outside active generation windows. | L4 GPU Lane Confirmed |
This is not a flat list of sites. It is a layered ecosystem with different operational characteristics: public business hosting, private control systems, AI compute, and serverless trading services.
Public-facing business and product stack
pixelpiraterij.nl as flagship business sitepixelpiraterij.online as broader product/system layerhub.pixelpiraterij.online as app and future browser-utility surfaceTrading, analytics and AI-assisted decision stack
Protected internal service family
hermetica.cloud command and presentation layerworkflow.hermetica.cloudchat.hermetica.cloudcommandcenter.hermetica.cloudnotebookos.hermetica.cloudSeparate organization / AI-business runtime
kunstvanvb-ai-vpsImage generation and model-heavy infrastructure
Experiment, notebook or auxiliary ML layer
This is the effective shape of the ecosystem based on verified runtime facts plus strong local documentation.
evaquant.tech and *.hermetica.cloud.
pixelpiraterij-vps hosts Coolify, Traefik, Directus, PostgreSQL, Redis, and the live public business stack.
europe-west4.
kunstvanvb-ai-vps as a distinct running system, and the project inventory confirms its dedicated disk resource in GCP.
The target state should centralize the business stack under Alibaba without collapsing all runtime classes into a single fragile machine.
Public websites, CMS, deployments, app hosting baseline
Image generation, models, inference and heavy AI workflows
Optional later host for internal-only services
The right Alibaba outcome is a unified business environment with clear role separation: public web and data services on one stable core host, GPU and model-heavy work on a dedicated AI node, and private internal tooling isolated only when the service map justifies it.
The migration path should minimize risk by building in parallel first, validating thoroughly, switching origins last, and only decommissioning old systems after proof.
Finish the cleaned service inventory for Hephaistos, the L4 lane, Kaggle burst usage, the live role of kunstvanvb-ai-vps, and the exact Hostkey service layout of the protected Hermetica family.
Prepare the new core web host with Docker, deployment layer, database services, backups, logging, security and reverse-proxy foundation before moving any public traffic.
Move the public business cluster first: PixelPiraterij sites, Hub, World, client sites, Directus content, PostgreSQL data, uploads and routing. Validate in parallel. Switch Cloudflare origin only after clean proof.
Stand up the GPU node with NVIDIA drivers, CUDA, Docker GPU support, model storage structure and backup policy.
Copy models, workflows, custom nodes and any essential outputs. Validate generation quality and performance before retiring any legacy GPU infrastructure.
Identify exactly where chat, workflow, command center and notebook services currently run, classify them by trust level, and only then decide whether they belong on Server A, Server B or a future Server C.
Break Quant EVA down into frontend, backend API, HMM worker/service, secret layer, integrations and traffic pattern. Only then decide whether to keep it on Cloud Run longer or self-manage it on Alibaba.
Retire or reduce old GCP infrastructure only after stable validation windows, working backups, clean logs, and confirmed service continuity.
These are the key areas where migration should remain deliberate rather than aggressive.
It already behaves like a small application platform with split frontend, backend and HMM-specific compute. Treating it like a single VPS copy would likely produce operational regressions.
Cloudflare Access, local configs and monitoring code together prove the protected Hermetica family is real and large on Hostkey. What still needs discipline is a clean service inventory for migration planning.
Hephaistos and ComfyUI style systems are not just about GPU power. Model directories, custom nodes, snapshots, workflow configs and disk layout matter just as much.
Kaggle appears in real service code, queue orchestration and NotebookOS runtime settings, so it belongs in the architecture as a burst-compute lane. The open question is current live remote session state, not whether Kaggle is part of the system.
One giant machine would increase blast radius, reduce isolation and make AI load compete with public web traffic. The cleaner business design is coordinated separation, not reckless compression.
The correct order is build, validate, switch, observe, then only decommission. This is especially important for image-generation and protected private services.
This section translates the technical reality into practical areas where Alibaba Cloud guidance adds immediate value.
Confirm the recommended separation between a core web/business host and a dedicated GPU/AI node, and advise whether a third private control-plane host should exist from day one or later.
Map the public web stack, the GPU/image-generation stack, and any later private internal services to the right Alibaba server classes, storage model and security posture.
Define the cleanest rollout model for public websites, databases, CMS content, AI nodes, and possible future private services while keeping Cloudflare in front.
Assess whether Kaggle-like experimentation should remain external, become hybrid, or be absorbed into a dedicated Alibaba GPU node once the live AI workload map is complete.
Support the decomposition of Quant EVA into clean service boundaries and help determine whether full self-management on Alibaba is operationally preferable to retaining serverless elements longer.
Advise on business-grade backups, storage segmentation, deployment hygiene, observability, GPU isolation, and a scalable hosting structure for future client workloads under the same ecosystem.
This handover is intended to remove ambiguity: the ecosystem is already a genuine multi-runtime product landscape, and its Alibaba future should reflect that reality.