How we keep ArduMaker servers secure, day by day

Published on 2026-09-12 by frfrand

La parte operativa, no la de diseño: qué se actualiza, qué se vigila, cómo se aíslan las cosas y qué pasa cuando algo se cae a las tres de la mañana.

We already explained how the platform is designed: closed ports by default, SSH with expiration, isolation by Company. That defines what is possible.

But real security is not defined by design; it is defined by routine. A well-designed server that is not maintained ends up being insecure anyway, just slower.

This is the operational part.

Updates that do not depend on anyone

Each VPS has automatic security updates enabled from the moment it is created.

It sounds obvious and it is, statistically, the measure that prevents the most attacks. The vast majority of intrusions into servers use known vulnerabilities, with a patch published months ago. There is nothing sophisticated: there is a server that no one updated.

We leave it enabled by default precisely because it is a task that is never urgent. If it depends on someone scheduling it, it does not get done.

Continuous monitoring, with history

There is a status system that checks hosts, VPSs, domains, and services in a continuous cycle, and keeps 45 days of history.

History is the most underestimated part. Knowing that something is down now is useful; being able to answer "how long has this been happening?" is what allows finding the cause. Many problems are not outages: they are slow degradations that are only visible by comparing against previous weeks.

And before escalating to a person, the system attempts to repair known failures on its own. A service that went down and is resolved by restarting it doesn't need to wake anyone up at three in the morning.

Copies elsewhere, and verified

Each VPS has a complete periodic copy, taken while running, stored on a host different from the one running the VPS.

Both parts matter and usually fail together:

• A backup on the same disk as the data is not a backup. It protects against accidental deletion and nothing else.
• A backup you didn't verify can be corrupt and you won't know until the worst moment. That's why they are stored with their hash: integrity can be checked before you need it.

And each copy comes with restoration instructions. It's the detail that separates a saved file from a recovery plan.

Isolation that doesn't depend on configuring it well

Each VPS is a separate machine, and each Company is separated from the others. There are no shared servers between clients nor cross permissions that can be misconfigured.

It is more expensive to operate than a well-configured shared server. The difference is that "well-configured" must be maintained every day, and structural separation maintains itself.

Everything is recorded

Every command executed on a VPS from the platform is recorded with who launched it and when. Every access opening, too.

The value does not show up in audits: it shows up on Tuesday, when something stopped working and the question is "what changed here?". With records it is a query. Without records it is a memory reconstruction among several people.

What this does not solve

It is worth saying, because promising more than what is delivered is its own form of insecurity.

None of this protects your application from its own errors. If your code has an SQL injection, if your keys are in the repository, or if someone on your team uses the same password everywhere, the platform cannot do much.

What we can guarantee is that the bottom layer is not the weak point, and that the most common infrastructure errors do not depend on someone remembering.