VPS servers

What can you do with it?

An ArduMaker VPS is a Linux server that belongs to the company: an isolated system container running Ubuntu 22.04, with root access and the resources of the chosen plan. Everything else is installed on top of it: apps, databases, Git deploys, services and scheduled tasks.

• Create a server choosing the plan, the location and the storage type (nvme, ssd or hdd, depending on what the location offers).
• Log in over SSH as root or as admin (with sudo), with random passwords unique to that VPS.
• Start, stop and restart the server, and move it to another plan (CPU, RAM and disk).
• Rename it, transfer it to another company and decide which members can see it (allowed and excluded lists).
• See its live status: CPU, memory, disk, uptime and running services.
• Know which features it supports given the operating system its agent reports.

When should you use it?

• You need a server with root to deploy an application, an API or a website.
• You want to install PostgreSQL, MySQL, Redis, n8n or WordPress without maintaining the machine by hand.
• You want an AI agent to operate the infrastructure over MCP with the same permissions you have in the dashboard.

How does it work in ArduMaker?

Creating a VPS answers right away with the creating status. Provisioning runs in the background for a few minutes and can resume: if something is interrupted, it continues from the last saved status.

1. creating: the container is launched with Ubuntu 22.04 and the plan's CPU and memory limits; then the plan's disk size is applied to the root disk.
2. create_api: the ArduMaker agent is installed inside; the platform reads the status and runs operations through it.
3. assigning_port: the VPS gets its own DNS name and the private path to the agent is set up.
4. updating_system: apt-get update, upgrade and autoremove, then a container restart.
5. installing_base_tools: sudo, curl, openssh-server, ca-certificates, python3-venv, python3-pip, Node.js LTS with npm and nginx; a random password for root and the SSH policy.
6. creating_user: the admin user with sudo and a random password that must be changed at first login.
7. active: the VPS is ready. ArduMaker opens SSH for 6 hours and sends the welcome email with the server, port, user, initial password and a ready-to-paste ssh command.

The platform can also create the VPS from an up-to-date base image. In that path the intermediate statuses are importing_base, customizing (new SSH host keys, its own random passwords, hostname) and verifying. If verification fails, the container is destroyed and created through the normal path: a half-built VPS is never delivered.

Every new VPS is born with the container permissions Docker needs (nesting and system call interception), without being privileged. The Docker daemon is not installed by itself: it is installed when you ask for it or when an app needs it. If the host does not accept those permissions, the VPS is created anyway, more restricted, and Docker shows as unsupported.

What actually changes?

VPS statuses

Deletion and final copy

When a VPS is deleted a final copy is kept, visible and downloadable only by company admins. Its term depends on the reason: 90 days if it was deleted for non-payment; while the account stays open if the customer deleted it (who can ask for it to be erased); 30 days if the company was closed. Admins get an email 7 days before it is erased.

Diagram

Expected result

The VPS shows as active in the dashboard and in listar_vps. ver_estado_vps returns, under system_status, CPU, memory, disk, uptime and services read from the server itself.

• To log in, use the ssh command from the welcome email while the 6-hour window is open. Afterwards it is reopened from the VPS port management.
• ver_funciones_vps confirms which features are available on that system before installing anything.

Errors and troubleshooting

Creation progress is followed with ver_vps (status field). If a creation call was cut off and you do not know whether it went through, repeat it with the same idempotency_key and the same arguments: it returns the original VPS instead of creating another one.

MCP access

The whole VPS lifecycle except deletion can be operated over MCP with the permissions of the person who authorized the agent. Full reference at /mcp/docs and in the /mcp/vps domain.

An agent authorized as read-only sees the read tools but not the ones that modify. Before crear_vps, the agent should check elegibilidad in listar_planes_vps and, if the location matters, ver_opciones_vps.

Related features

• VPS plans
• Web terminal
• Linux users
• Firewall and ports
• Backups
• Monitoring