The Dan Peters Designs website has officially moved.
DPD is now running from our own Amadi web infrastructure, with the live site hosted on Amadi Web and a second Amadi server standing by with a complete synchronized copy.
That sounds like a server story.
It really isn’t.
It is a story about owning the things we depend on — and building them so one broken machine does not ruin your day.
Moving the Website Without Burning the Bridge Behind Us
Until now, the live DPD website had been running from Harbor, one of the machines that has carried a lot of our projects while the larger Amadi system was being built.
The new production home is Amadi Web.
We migrated the WordPress site, database, configuration, and the media the live website actually uses. We did not destroy or overwrite the original Harbor installation in the process.
Harbor still holds that original copy.
That gave us a migration path with a way back instead of the considerably less sophisticated strategy of crossing our fingers.
The completed move was checked across all 87 published URLs, including pages, posts, media, stylesheets, WordPress services, and the tools we use to manage the site.
The live site is now running normally from the new machine.
One Live Server Wasn’t Enough
Moving the site was only half the job.
A server can fail. A drive can die. Somebody can make a mistake. Software can break.
So the second part of the project was making sure the website did not depend entirely on one box.
Our original Amadi web server now serves as the DPD standby system.
Every night, the live Amadi 12 server creates a fresh verified snapshot and sends it to the standby machine. The standby server only applies the snapshot after the transfer has completed successfully.
We tested the entire process rather than simply assuming it worked.
After synchronization, the two systems agreed on:
- 49 published posts
- 38 pages
- 296 media records
- the WordPress database
- the website files
- the DPD-created download repository
So if we ever need the backup, it is not just a pile of files that we hope can become a website.
It is a maintained copy of the website.
Keeping Different Jobs Separate
We’re also beginning to separate DPD’s storage by what the material actually is.
The web server has dedicated space for DPD-created downloads: our applications, Android packages, themes, artwork, MT Server material, ZIP files, checksums, and other things we build.
Books, manuals, reference material, educational collections, Kiwix content, and similar shared resources belong on the database and library side of the Amadi infrastructure instead.
To visitors, that can still look like one simple DPD downloads address.
Behind it, different machines can do the jobs they are better suited to do.
That separation matters because the goal is not to pile everything onto one enormous server and call it infrastructure.
The goal is to build something understandable, maintainable, and repairable.
Plenty of Room Without Wasting the Machine
Amadi Web currently reserves 100 GiB specifically for DPD.
Half is reserved for the WordPress website, and half for DPD-created downloads.
At the moment, the entire website uses only about 614 MB, and the DPD download area uses about 12 MB.
That gives us a lot of room to grow while leaving most of the server’s roughly 1 TB data drive available for its other job: hosting customer websites.
That is an important part of how we’re approaching the Amadi systems.
We are not buying giant new cloud services every time we need another function.
We’re taking affordable, reusable enterprise hardware and giving each machine a clear job.
This Is Becoming an Infrastructure Project
DPD started with individual projects.
A website here. An application there. MT Server growing into its own platform. A collection of reference material. Some servers that could be put back to useful work.
Those pieces are beginning to connect.
The larger Amadi design now includes separate systems for management, WordPress hosting, database and library services, and community services.
DPD is also building its own software alongside that infrastructure, including Palletize-It, Chaos Journal, Headache Journal, Household Schedule, and the small Whimsy game experiments.
MT Server remains its own separate project: a local-first server platform designed to make useful self-hosted services more approachable for homes and smaller organizations.
The common thread isn’t the hardware.
It is ownership.
We want systems we can understand, repair, move, back up, and keep using without discovering that some outside company changed the terms.
There is nothing especially glamorous about a backup server quietly receiving a snapshot at 2:15 in the morning.
That’s sort of the point.
Useful infrastructure should mostly just work.
Next: The Other Half
The web side is now redundant and operational.
The next step is the database and library side.
Original Amadi 03 will be brought online and turned into the backup counterpart for Amadi 13 DB/Mirror, extending the same redundancy model to the shared database, library, and distribution infrastructure.
One side at a time, we’re turning a collection of machines into something much more useful:
infrastructure we actually own.