Why my two servers talk to each other through OneDrive
Two VPSes, identical spec, same provider, same datacentre, sitting probably metres apart in physical reality. The way they exchange files is through a Microsoft consumer cloud product. I’m aware of how that sounds.
The rule is simple and absolute. AXIOM and AUTO do not have credentials for each other. No keys, no allowlists, no SSH tunnels, no rsync over the wire. They are network neighbours who do not speak. If you sat at AUTO’s shell and tried to reach AXIOM directly, you’d get nothing back, because nothing about AUTO’s identity is permitted on AXIOM, and vice versa.
The reasoning isn’t paranoid. It’s about blast radius. AUTO is the dev mirror. I do experimental things on AUTO. I break it on purpose, sometimes. I run permission audits and migration tests and the occasional misconfigured nginx vhost that takes the whole panel out for ten minutes. If AUTO and AXIOM had a direct trust relationship, anything that compromised AUTO would have a clear path to production. By keeping them mutually deaf, the worst case for AUTO going wrong stays contained to AUTO.
So how does anything actually get from dev to live? OneDrive sits in the middle holding deploy bundles.
The mechanism is dull and that’s the point. When something on AUTO is ready to ship – a theme update, a plugin change, a fresh export of a WordPress site – it gets bundled up locally and pushed to a specific folder in my OneDrive. AXIOM, on its own schedule and using its own separate set of credentials, pulls from that same folder when it’s looking for new bundles. AUTO never sees AXIOM. AXIOM never sees AUTO. Both of them see OneDrive, and OneDrive has its own auth boundary with its own MFA and its own audit trail.
The bit that surprised me is the speed. I’d assumed routing files through a third-party cloud would feel like dial-up. It does not. AUTO is uploading from a London datacentre on whatever ridiculous fibre these boxes come with, and AXIOM is downloading on the same kind of pipe. The bottleneck, if there is one, is OneDrive’s own ingest rate, and OneDrive’s ingest rate is fine. Bundles that I’d expected to take minutes take seconds. The relay is not slower than direct transfer in any meaningful way.
There’s a structural symmetry to this that I like. Back during Phase 7, when AUTO was first set up as the mirror, the relay ran the other direction – live sites on AXIOM were exported and pulled down into AUTO so that dev would actually reflect production rather than being some idealised version that didn’t match reality. Same mechanism, opposite direction. AXIOM pushes a backup bundle up, AUTO pulls it down, dev gets refreshed. Now that the workflow is established, the dev-to-live path is just the same pattern running in reverse. The relay was already there. I just needed to commit to using it as the only path.
First real test was the Vulcan deployment. vulcan.institute had been living on AUTO as the dev version while the theme work was finalised, and the moment came to move it across to production. I bundled it on AUTO, pushed to OneDrive, watched the file land in the folder, then went over to AXIOM and pulled it down. Five minutes, all in. The site came up on its production hostname looking identical to the dev mirror, which is what you want and not always what you get.
The version of me from a year ago would have set up rsync over SSH and called it done. It would have worked. It would also have been a quiet single point of failure that I’d have forgotten about until the day someone got into one of the two boxes and walked straight into the other.
This isn’t elegant. It is, on paper, a fairly silly arrangement. Two servers in the same building shouting at the cloud to talk to each other. But silly and correct beats elegant and brittle, and I’ve stopped feeling self-conscious about the OneDrive bit.
Connor’s checkout works. The relay does what it’s meant to do.