Who ArduMaker's cloud is designed for
Published on 2026-09-12 by frfrand
Tres perfiles donde encaja bien, dos donde no, y la pregunta honesta que conviene hacerse antes de mover infraestructura.
Instead of listing features, it's worth describing three concrete situations. If you recognize yourself in any of them, it's probably a good fit. If not, better to know beforehand.
1. The freelancer with several clients
You have five or ten clients. Each with their own site, their own domain, maybe their own email.
Typical problems of that situation:
- Everything mixed on the same server, because separating was expensive.
- The bill arrives together and you have to do the math to figure out how much corresponds to each client.
- If a client leaves, separating their stuff is archaeology.
With a Company per client, each one has their own VPS, their own domains and their own balance. The invoice already comes separated and can be transferred without calculating anything. And the day a client leaves, everything goes together.
2. The small agency
Five, ten, fifteen people. Developers come and go, projects come and go.
The pain here is access: the shared password that nobody changes, the freelancer from eight months ago who still has the key, the awkward question of who can touch which client's server.
The answer we give: each person with their own account and their own SSH key, permissions per Company, and roles that separate who works from who handles billing. Removing someone is one action, in one place.
3. The team that publishes frequently
A own product, a small team, several deployments per week.
What they are looking for there is that deploying be boring: link the repository, choose the branch, and every push does the rest with its log. And being able to have staging and production on the same VPS, with different domains, without building it by hand.
Where it doesn't fit
Saying it makes the above more credible:
If you need global presence. Twenty regions, replication between continents, latency optimized by zone. Big providers do that well.
If you depend on proprietary services from another provider. If your application is built on five specific managed services, moving it is rewriting it, and it's probably not worth it.
If you have an infrastructure team. If there are people whose job is this, they will probably prefer to build it custom, and they are right to do so.
If the only criterion is price per resource. You can always rent a bare server for less. What you pay for here is what comes solved.
The honest question
Before moving infrastructure, it's worth measuring three things in your current situation:
New client, new site. From scratch to working with HTTPS, how long does it take?
Someone leaves the team. How many places do you have to touch to remove their access to everything?
A client asks how much they owe. Can you answer without doing the math?
If all three answers seem reasonable to you, you have a good system and there's no need to change anything. If any of them makes you uncomfortable, that's the problem we solve.
