This client’s warehouse management system was custom-built. Not WordPress, not an off-the-shelf product with a documented install script, but their own stack, doing their own picking, stock and delivery workflow.
That rules out generic hosting. It needed its own server, configured for what the application actually runs, and locked down before a single real stock record went near it.
Hardened at deployment, not afterwards
Security work is much cheaper before go-live than after. Once a system is carrying live warehouse data, every change has a blast radius and a scheduling conversation attached to it.
So the hardening happened as part of the deployment: SSH restricted to keys with no password login, a firewall that denies by default and opens only the ports the application needs, no unnecessary services listening at all, automatic security updates, and TLS terminating in front of the application.
None of that is exotic. It is simply much easier to do on day one, when there is nothing to break and nobody depending on the box yet.
Media goes to object storage, not to the disk
The interesting design decision was where the files live.
A warehouse system produces a constant stream of media: product photos, delivery notes, scanned proof of receipt, damage evidence. Keep all of that on the application server and you have signed up for a disk that grows forever, backups that get slower every month, and a migration nightmare the first time you need a bigger machine.
Instead, the application pushes and pulls media directly against Aliyun object storage. The server runs the application; the bucket holds the files. Three things follow from that:
- Storage scales on its own. Nobody has to watch a disk usage graph or plan a resize.
- Backups stay small and fast, because the server backup is configuration and database, not gigabytes of photographs.
- The server becomes disposable. It can be rebuilt, resized or replaced without a single document being at risk, because none of the documents were ever on it.
The pattern underneath
Give the workload a server shaped for it, close everything you are not using before it goes live, and keep the data that grows without limit somewhere built for data that grows without limit.
Done in that order, the interesting parts of the system stay interesting, and the infrastructure underneath stops being something anyone has to think about.
Server builds and hardening like this are project work, and keeping the box patched afterwards is what a Care Plan covers. If you have a custom application that needs a server of its own, get in touch and tell us what it runs on.