Software esencial para VPS: qué instalar según cada caso de uso

Un VPS recién creado es la misma caja vacía tanto si se compró para alojar un sitio web como para ejecutar un bot de trading. El mismo punto de partida limpio, el mismo disco casi vacío, casi nada más allá del sistema operativo. Lo que se instala en él diverge desde la primera instalación y ya no vuelve a coincidir: una pila web y una pila de trading casi no comparten software, y una de ellas ni siquiera usa el mismo sistema operativo.

Así que no existe una lista única de software esencial para VPS. Existe una capa base corta que todo servidor necesita, sea cual sea el motivo de la compra, y a partir de ahí el caso de uso lo decide todo. Dos de las decisiones previas a esta también cambian la forma de esa capa base. Alojamiento compartido frente a un VPS determina si tienes acceso root o no. Gestionado frente a no gestionado determina de cuántos de los cinco elementos siguientes eres responsable tú mismo.

LEER

KVM vs. OpenVZ vs. LXC: qué te permite hacer realmente el tipo de virtualización de tu VPS

TL;DR

• No hay una respuesta universal. Más allá de una capa base corta, el caso de uso elige los programas y, a veces, el sistema operativo.
• Todo VPS necesita primero las mismas cinco categorías: acceso de administración seguro, un firewall que esté activado, una política de actualizaciones, copias de seguridad que hayas restaurado al menos una vez y algo que te avise de que la máquina sigue viva. En Linux, el acceso de administración seguro suele significar SSH con claves; en Windows, significa proteger RDP u otra vía de administración.
• Tres cosas que un VPS Linux de 1 o 2 GB no debería añadir por defecto: un panel de control, un antivirus y el filtrado de spam y virus que incluye una pila de correo. Sus requisitos de memoria documentados pueden consumir la mayor parte o la totalidad de una máquina pequeña antes de que empiece tu carga de trabajo real.
• A continuación vienen diez casos de uso de VPS, cada uno con los programas que hacen el trabajo y la restricción que decide si cabe en la máquina que compraste.
• Cada sección aquí es el mapa. Las guías enlazadas aportan la profundidad.

Lo que necesita todo VPS, sea cual sea el motivo de la compra

Lo primero que hay que instalar en un VPS nuevo no tiene nada que ver con el motivo de la compra. Cinco elementos van primero, los mismos cinco tanto si la máquina acaba ejecutando una tienda online como un servidor de juegos.

En Linux, empieza con SSH basado en claves. Genera un par de claves, coloca la clave pública en el servidor, confirma en una segunda sesión que el inicio de sesión con clave funciona y después desactiva la autenticación por contraseña, porque un puerto con autenticación por contraseña en una IP pública es un imán para intentos de inicio de sesión.

Después, el firewall, y comprueba que está en marcha en lugar de darlo por hecho. Ubuntu incluye UFW como herramienta de firewall predeterminada, y la documentación de la comunidad de Ubuntu indica que UFW está desactivado por defecto. Preinstalado no es lo mismo que activado. Si estás conectado por SSH, permite primero tu puerto SSH real, luego activa UFW y abre solo los puertos adicionales que necesite la carga de trabajo. Con la configuración predeterminada, esa primera regla es sudo ufw allow 22.

Si además entra en juego un firewall de aplicaciones web, empieza por las categorías. Las opciones de firewall gratuitas para un VPS Linux se dividen en cuatro categorías fáciles de confundir.

La política de actualizaciones va en tercer lugar, y el valor predeterminado depende de la distribución. La guía de actualizaciones automáticas de Ubuntu Server indica que instala el paquete por defecto y aplica automáticamente las actualizaciones de seguridad. Ese paquete es unattended-upgrades.

Debian no hace esa promesa. La wiki de Debian advierte que un sistema «podría no haber instalado el paquete en absoluto, o podría haberlo instalado pero desactivado por completo». Para comprobar si está activado y configurarlo, ejecuta sudo dpkg-reconfigure unattended-upgrades.

Las copias de seguridad van en cuarto lugar, y la regla es una restauración. Una copia de seguridad que nadie ha restaurado nunca es una hipótesis. Restaura una en un servidor desechable, mira cómo arranca y entonces sí es una copia de seguridad.

En quinto lugar está la monitorización, algo que te avise de que el servidor se ha caído antes de que lo haga un usuario. Un comprobador ligero de disponibilidad basta. No existe una fórmula fiable que convierta el número de monitores en memoria, así que empieza con 1 vCPU y 1 GB y observa.

Más allá de esos cinco, el hardening es un proyecto en sí mismo, no un paso. Dos guías ya lo cubren:

• Una checklist de 20 puntos para proteger un VPS Linux
• La checklist de hardening para un VPS Windows

Ahora la mitad más difícil: qué no añadir por defecto en un VPS Linux de 1 o 2 GB. CloudPanel requiere al menos 2 GB de RAM antes de que tus sitios usen nada. La propia documentación de ClamAV recomienda 3 GiB o más. Y la guía de Virtualmin para poca memoria recomienda desactivar por completo SpamAssassin y ClamAV cuando la memoria es escasa.

Son requisitos y recomendaciones de los fabricantes, no preferencias. Hacen que los tres sean malas opciones por defecto en una máquina pequeña, salvo que ese software forme parte de la carga de trabajo para la que realmente compraste el VPS.

Qué ejecuta cada caso de uso

Lo que varía entre estas diez situaciones no es tanto el tamaño de la máquina como qué dos o tres programas tienen que existir antes de que nada más importe, y qué restricción suele decidir lo grande que debe ser esa máquina.

La tercera columna es la que hay que leer dos veces. Más CPU es la mejora refleja, y en varias de estas filas no es la restricción que manda.

Alojar un sitio o una aplicación web

La decisión que da forma a este servidor no es qué servidor web es más rápido. Es quién gestiona los certificados TLS. Caddy los emite y los renueva por sí mismo sin herramientas adicionales. NGINX espera un cliente ACME independiente como Certbot y más configuración manual, y a cambio ocupa menos memoria en reposo. La comparativa Caddy vs. NGINX pone los dos archivos de configuración uno al lado del otro, por si ese equilibrio necesita comprobarse antes de decidirte por uno.

El resto sigue a la aplicación y no al revés. Muchas aplicaciones dinámicas necesitan una base de datos, y que sea MariaDB o PostgreSQL suele decidirlo lo que admite la aplicación más que la preferencia. Redis se gana su sitio cuando la aplicación realmente necesita caché, sesiones, colas u otra función basada en Redis. Y si más de un sitio o servicio va a compartir el servidor, un proxy inverso, es decir, el proceso que se sitúa delante y dirige cada petición a la aplicación correcta según el nombre de host, acaba con el malabarismo de puertos antes de que empiece. Nginx Proxy Manager pone una interfaz gráfica a esa tarea y funciona holgadamente con 2 GB. La guía de instalación de Nginx Proxy Manager explica el proceso paso a paso.

Una advertencia, y apunta a alejarse del VPS por completo. Si el trabajo es un único sitio pequeño sin requisitos especiales, el alojamiento gestionado es una respuesta defendible y un servidor que administras tú mismo es trabajo extra sin ninguna ganancia. El VPS se justifica en el momento en que el sitio necesita algo que un plan gestionado no te va a instalar.

Sustituir herramientas SaaS de pago por otras autoalojadas

Aquí Docker es la decisión que marca el orden, y va antes que cualquiera de las aplicaciones por las que viniste. Un runtime de contenedores mantiene cada servicio y sus dependencias aislados en su propia caja, de modo que la versión de PHP de Nextcloud y las bibliotecas de aprendizaje automático de Immich nunca discuten entre sí. Portainer o Dockge dan a ese runtime una interfaz web y un lugar donde ver qué se está ejecutando. Coolify va más allá y convierte el servidor en algo más parecido a una plataforma de despliegue, con builds por git push y TLS automático. Elige la capa de gestión después del runtime, no en su lugar.

Consejo pro: Instala Docker desde el repositorio del propio Docker en lugar del de la distribución. La documentación de instalación de Docker califica de no oficial el paquete que proporciona la distribución e indica que hay que eliminarlo antes de instalar Docker Engine. Ese paquete es docker.io.

Las aplicaciones en sí son la parte fácil, y justo ahí está el problema. Un hilo de r/selfhosted sobre qué servicios autoalojados conserva la gente a largo plazo lo deja claro. El autor del hilo enumera una serie de sustitutos que configuró y luego abandonó, y ninguno falló en el paso del despliegue. Los motivos que da tienen que ver con el pulido de la experiencia de usuario y con el miedo a perder el acceso. Un VPS resuelve de lleno la segunda mitad, porque no depende de la electricidad de casa ni de que una conexión residencial siga activa. No hace absolutamente nada por la primera mitad.

Trading: forex, algorítmico y cripto

Esta es la única sección en la que el sistema operativo puede cambiar. MetaTrader 4 y MetaTrader 5 son aplicaciones de Windows, así que un servidor de trading sigue siendo habitualmente un Windows Server al que se accede por RDP. MetaQuotes también admite ejecutar MetaTrader en Linux mediante Wine, por lo que Windows es la vía nativa más sencilla y no un requisito estricto. QuantRocket es el extremo de investigación algorítmica y cuantitativa de la misma lista, y BTCPay Server gestiona los pagos en cripto. Ambos son cargas de trabajo Docker en Linux.

Las especificaciones importan menos que el mapa. Un trader de r/VPSforTradings que planeaba un bot de MT5 con cinco brókers preguntó qué VPS ofrece la latencia más baja hasta el centro de datos concreto de cada bróker, y esa es la pregunta que lo decide. Los endpoints de los principales brókers se agrupan en torno a unos pocos nodos de centros de datos, y lo que hay que medir es la ruta de red entre tu VPS y el endpoint del bróker. Dos servidores con procesadores idénticos en redes distintas o en ciudades distintas pueden comportarse de forma muy diferente para este trabajo.

Lo que convierte la mejora obvia en la equivocada. Comprar más núcleos no acorta la ruta. Elegir la ubicación de un VPS para forex antes que el plan es donde se toma esta decisión.

Mantén tu trading en línea 24/7 con un VPS Forex de baja latencia.

Obtener VPS de Trading

Ejecutar una VPN privada o una red en malla

Aquí existen dos formas y no son intercambiables. Un servidor WireGuard en el VPS da a tus dispositivos una ruta cifrada hasta ese servidor y hasta todo lo que enrutes a través de él. WireGuard Easy envuelve esa configuración en una interfaz web, de modo que añadir un peer deja de significar editar un archivo de configuración a mano. Una red en malla como Tailscale es otra cosa: los dispositivos intentan conectarse directamente entre sí, pero el tráfico puede usar un relay entre peers o un relay DERP cuando no es posible una ruta directa. Su capa de coordinación distribuye la información que los dispositivos necesitan para descubrirse y conectarse entre sí. OpenVPN AS, Pritunl, ZTNET y WGDashboard cubren el espacio entre esos dos extremos.

Un hilo de r/selfhosted sobre esa elección sacó a la luz la verdadera preocupación de depender de Tailscale. Uno de los que respondieron dijo que solo le preocupaba «que Tailscale se degrade mientras intenta ser rentable». Es una preocupación por el proveedor, no por el precio. Ejecutar el túnel tú mismo saca a esa empresa de la cadena.

También añade trabajo. Un servidor de coordinación gestionado supone realmente menos operación, y para un portátil que llega a un solo servidor, montar tu propia malla es más maquinaria de la que el problema necesita. WireGuard a secas basta para ese caso.

Alojar un servidor de juegos

El juego es la instalación fácil y el panel es la decisión. Solo Minecraft tiene varias variantes de servidor, y cuál ejecutas depende de lo que quieras obtener: Paper para rendimiento en un servidor de supervivencia normal, Forge o Quilt cuando un modpack es todo el sentido. Ejecutarlo directamente en el servidor funciona bien. Ejecutarlo bajo Pterodactyl Panel con su daemon Wings, o bajo PufferPanel, aporta límites de recursos por servidor, una consola web y una forma de dar a un amigo permisos para reiniciar sin darle acceso SSH. Nakama es un producto totalmente distinto, para quienes crean un juego en lugar de alojarlo.

Una guía de r/admincraft recorre todo el camino desde un VPS vacío hasta un servidor con mods automatizado que funciona sobre Pterodactyl, lo que da una buena idea de lo que aporta la vía del panel.

El coste es un segundo sistema que mantener parcheado, y nunca deja de serlo. Para un único servidor vanilla con seis amigos, el panel es más infraestructura de la que el juego necesita. El número de mods es la otra variable a vigilar. Modificar un servidor de ARK con mods muestra lo que eso implica en la práctica. Todo lo que sea público también necesita protegerse antes de que alguien lo encuentre, y la guía de seguridad para servidores de Minecraft cubre ese paso.

Ejecutar modelos de IA e inferencia local

Ollama ejecuta el modelo y Open WebUI es la interfaz acoplada encima. LiteLLM solo se gana un sitio delante cuando las llamadas necesitan enrutarse entre proveedores, y Qdrant solo cuando la recuperación forma parte del plan.

Sin GPU, el techo llega rápido. Alguien que probaba Ollama en un VPS de 8 GB solo con CPU se topó con un error de falta de memoria: el modelo necesitaba 7,2 GiB y había 3,8 GiB libres, porque el sistema operativo y Coolify ya se habían llevado la diferencia. Los modelos cuantizados pequeños, es decir, con pesos almacenados a menor precisión para caber en menos memoria, pueden ejecutarse en una CPU si el modelo y el runtime caben en la RAM del sistema. Si caben, la contrapartida habitual es una inferencia más lenta; si no caben, el proceso puede fallar con un error de falta de memoria.

La calidad es el segundo límite. Un hilo de r/selfhosted sobre si merece la pena autoalojar Ollama ofrece la otra cara. Un comentarista describió los modelos abiertos que había probado como de «peor calidad» y dijo: «no vas a ganar a estos gigantes de miles de millones de dólares». Es la experiencia de un usuario, no una regla para todos los modelos abiertos. Autoalojar te da control sobre los datos y la infraestructura; que supere a una API alojada en calidad o coste depende del modelo, la carga de trabajo y la utilización.

Las cuentas de costes frente a una API alojada muestran dónde cambia la economía. Modelos más grandes, más concurrencia u objetivos de latencia más estrictos lo convierten en una cuestión de hardware. Los planes GPU VPS de Cloudzy están pensados para ese caso.

Un escritorio remoto o una estación de trabajo en la nube

Detrás de la expresión «escritorio remoto» se esconden tres mecanismos distintos, y elegir por nombre de producto en lugar de por mecanismo es como la gente acaba con el equivocado. Una sesión RDP es un escritorio real que se ejecuta en el servidor y en el que inicias sesión. La imagen de un clic IceWM over XRDP de Cloudzy es aquí el paquete ligero: incluye IceWM, Terminator, Falkon y un listener xRDP con TLS, mientras que Linux Mint te da un escritorio completo en lugar de uno mínimo.

Kasm Workspaces puede ofrecer aplicaciones y escritorios en contenedores bajo demanda en un navegador, pero también puede exponer servidores RDP, VNC, SSH y KasmVNC existentes mediante Server workspaces. Neko es distinto otra vez: transmite un único navegador virtual compartido por WebRTC a varias personas en una sala, que no es un escritorio en el que alguien inicie sesión.

Si lo que quieres es el propio escritorio del servidor, usa un Kasm Server workspace basado en RDP o VNC en lugar de un workspace de contenedor. La documentación de Kasm sobre infraestructura fija cubre esa configuración. Las sesiones nativas en contenedor de Kasm son entornos separados, no el escritorio del host.

Si la máquina que quieres ya existe y solo necesitas llegar a ella, RustDesk llega sin construir ningún escritorio, y Sshwifty te da una shell en el navegador cuando una shell era todo lo que necesitabas. Decide el protocolo antes que el nombre del producto. Conectarse por RDP y transmitir una sesión de navegador no son lo mismo con distintas etiquetas.

Una máquina de desarrollo, builds y CI

Code Server pone VS Code en una pestaña del navegador apuntando al sistema de archivos del servidor, y eso es lo que hace que merezca la pena mantener junto el resto de la máquina: Gitea o Forgejo con los repositorios que abre el editor, Jenkins ejecutando los pipelines que disparan esos commits y Docker por debajo de ambos. La pieza más nueva son los agentes de programación con IA que ahora viven en esa misma máquina: Claude Code, Aider, OpenCode y Goose CLI.

Esa configuración obvia no es la única. Un hilo de r/selfhosted sobre entornos de desarrollo remotos tuvo a uno de los participantes defendiendo lo contrario: mantener el editor instalado en local y apuntarlo al VPS mediante una extensión de desarrollo remoto, para que la interfaz siga siendo local y solo los archivos y la ejecución sean remotos. La queja del autor del hilo era que el host capturaba los atajos de teclado en lugar del navegador, un coste real de la versión en el navegador.

Ambas son legítimas. Ejecutar Code Server con un agente de IA recorre la vía del navegador de principio a fin. La pila de desarrollo autoalojada reúne todo lo que rodea al editor.

Automatización, bots y tareas programadas

n8n es el punto de partida habitual, y es una opción predeterminada razonable: un constructor visual de flujos de trabajo donde los nodos son servicios y las conexiones son datos que se mueven entre ellos. Activepieces hace un trabajo similar con una licencia más permisiva. Node-RED aborda el mismo problema desde el otro extremo, basado en flujos y centrado en el cableado de dispositivos y eventos más que en unir servicios SaaS. Dagu es un planificador de grafos de dependencias, adecuado cuando lo que tienes es en realidad un conjunto de tareas cron que necesitan un orden.

Estos servicios siguen en marcha entre tareas. Su uso de recursos crece con la actividad de los flujos de trabajo, mientras que el historial de ejecución conservado hace crecer sobre todo la base de datos y el almacenamiento. Eso lo convierte en el tipo de carga de trabajo que puede superar en silencio al servidor más pequeño unos meses después de haber parecido suficiente. La comparativa de alternativas autoalojadas a Zapier recoge el detalle de licencias y el dimensionamiento.

Servir contenido multimedia

El almacenamiento suele ser la primera restricción aquí, pero la transcodificación puede convertir la capacidad de CPU o GPU en la decisiva. Jellyfin para vídeo, Navidrome para música y Audiobookshelf para audiolibros y pódcasts reúnen cada uno un escáner de biblioteca, un recolector de metadatos y un servidor de streaming en una sola aplicación que se instala como cualquier otro servicio web, y AzuraCast (una emisora de radio web) e Immich (fotos) siguen el mismo patrón.

Eso hace que un VPS sea la forma equivocada más a menudo que no. Transcodificar al vuelo cuesta tiempo de procesador que un servidor pequeño no tiene de sobra, y una máquina en casa con discos grandes suele ser mejor anfitrión para la propia biblioteca, mientras el VPS se gana su sitio por el acceso remoto y por mantenerse en línea. La comparativa de alternativas a Plex repasa qué servidor encaja con qué cliente.

Lo que te toca una vez todo está instalado

Cada programa mencionado arriba llega con una tarea asociada. Alguien lo parchea, vigila su memoria, renueva su certificado y comprueba si la copia de seguridad se restaura. En un VPS autogestionado ese alguien eres tú, y la carga se acumula con cada una de estas situaciones que acaba en una misma máquina.

La mitad de instalación es la que vale la pena acortar. Si el software que eliges está disponible como aplicación de un clic, eso acorta el paso de instalación en lugar de dejarte con un servidor en blanco y una pestaña de documentación abierta. Un VPS Linux de Cloudzy te da ese punto de partida, para que la primera hora se dedique a aquello para lo que compraste el servidor. La mitad de operación sigue siendo tuya en cualquier caso. Esa parte no se externaliza.

Construye sobre un VPS Linux con acceso root, NVMe y la potencia de AMD EPYC.

Ver planes Linux

Preguntas frecuentes