The first article in this series promised a separate look at the month's main story: the migration from rented virtual machines to dedicated bare-metal servers. It is invisible from the outside: the same websites, bots, and status dashboard. What changed was the foundation beneath them, and that explains almost all the figures from Arcanada's second month.
There were almost no new outward-facing products. After Coworker, Disk Arcana, and Transcribator, the month was spent not expanding the storefront, but going deeper—working on the foundation that supports it.
Why task complexity increased
The share of complex tasks—L3 tasks (PRD required) and L4 epics—among those labeled rose from 29% to 33%. In absolute terms, the second period had 79 L3 tasks and 22 L4 epics.
A note on methodology: the complexity field was added to the archives only in May, so 29% of April is labeled, compared with 86% of June. Absolute numbers at each level cannot be compared across periods—this reflects a labeling imbalance, not a manyfold increase in complexity. Only the shares within each period are comparable.
The reason for the increase is clear from the database migration. Moving the database from a cloud machine to a dedicated server was split into six stages: schema backup, replication, test run, traffic cutover, integrity validation, and decommissioning the old instance. Each stage was a separate L3 epic with its own PRD, tests, and acceptance criteria. In the cloud, this is a single API command; on bare metal, it is six epics.
Tails
The signature term of the month — "tails". Moving one service drags a chain of dependencies behind it: DNS, certificates, firewall rules, database connections, and monitoring agents. Resolve one tail, and two more appear.
For example, the database was moved to a new server in a day, but it had fifteen consumers: services, queues, and background jobs, each storing its address in its own configuration. Switching them live, one by one, would have meant hours of connection errors across the entire system. Instead, the list of consumers was collected from the repositories, and the cutover was performed through the build pipeline—one coordinated step instead of fifteen disconnected ones.
The visible part, moving the database, took a day; the invisible part, moving all its dependents, took a week. Tails like these accounted for dozens of epics over the month, which is why the second month was harder than the first despite a comparable number of completed tasks.
Shift in focus: top projects
The shift is visible in the top projects by number of archives. In the first period, the focus was on the framework and model connectors:
| Period 1 (Apr→May) | Archives |
|---|---|
| Datarim (framework) | 101 |
| Model Connector | 58 |
| Infrastructure | 48 |
| Auth Arcana | 30 |
| Transcribator | 24 |
In the second, infrastructure and managed spaces came to the forefront:
| Period 2 (May→Jun) | Archives |
|---|---|
| Datarim (framework) | 85 |
| Infrastructure | 37 |
| Managed spaces | 25 |
| Arcanada core | 23 |
| Status dashboard | 22 |
The share of infrastructure projects increased. Managed spaces and the status dashboard did not exist at all in the first period—the migration could not have been coordinated without them.
Why bare metal instead of more cloud
The cloud is convenient when there are few services. At dozens—databases, proxies, dev and prod environments, queues, caches—renting becomes expensive and opaque: billing is based on peak rather than average load.
A dedicated server is a fixed price for specific hardware, with full control over its utilization. Several underutilized machines provide more headroom for autonomous agents than the same budget spread across cloud instances: an agent can deploy a new service without running into someone else's limit.
Over the month, the fleet shrank from roughly 24 to 19 machines: the database and secrets store moved to a new dedicated node, two unnecessary servers were decommissioned, and two new dedicated machines were added—one for the database and one for development. The bill nevertheless rose above the first month's €216 baseline. This is a deliberate investment in the foundation, not an expansion.
The tradeoff is that hardware does not recover itself. In the cloud, a failed machine is replaced by another; on a dedicated server, diagnosis and recovery fall to agents with the necessary access and context. Running a dedicated server requires someone nearby—human or agent—who holds the entire chain in their head.
A foundation solid enough to loosen the reins
The month's main point: infrastructure is not an expense, but an investment in autonomy. On a rented virtual machine, a service is tied to someone else's SLA, pricing, and limits; on a dedicated server, control over the hardware, network, and access is complete.
For agents, this is critical. An autonomous agent cannot be trusted with production on an unreliable foundation: a task to deploy a service may hit a cloud limit on the number of machines, network latency, or an unavailable region—and the agent will stall waiting for a response. On dedicated hardware, these risks are minimized: the network is under control, resource capacity is known, and utilization is visible in real time.
The chain is direct: dedicated hardware—a predictable environment—loosened reins. The same logic supports the cycle's dual orchestration: a task starts locally, the orchestrator on the node distributes it to agents in separate sessions, and every layer is only as solid as the foundation beneath it.
What's next
The migration is not the finish line, but the beginning. Three directions come next:
- Finish the tails—the services still running on cloud machines. Each is an L3 epic with a risk of bringing down a live system.
- Automated deployment to bare metal, so agents can bring up services without manual intervention, knowing that the environment is predictable.
- Hardware metrics in the status dashboard: disk temperatures, processor utilization, SMART errors—agents should see infrastructure health just as an operator does.
A month without a new outward-facing product looks like standing still, and I understand that frustration because I feel it myself. But infrastructure debt is like interest on a loan: if it is not paid now, it will cost twice as much later, when an autonomous agent brings down production on an unreliable foundation. The foundation is ready; the next month—with autonomous agents, commercial projects, and open-source code—would have been impossible without this stage.