Cómo desinstalar CloudPanel en Ubuntu sin perder datos

Desinstalar CloudPanel de Ubuntu no es tan simple como borrar un paquete. El panel forma parte de un entorno que también incluye servicios del servidor, bases de datos, usuarios, archivos y configuraciones. Por eso, quitar el paquete del panel no equivale a eliminar todo lo que se configuró durante la instalación ni garantiza que Ubuntu vuelva a su estado anterior.

Si querés retirar CloudPanel por completo y empezar de cero, la opción más previsible es respaldar los sitios y las bases de datos y reconstruir el VPS con una imagen limpia de Ubuntu. Si necesitás conservar el sistema operativo y las aplicaciones alojadas, primero hay que inventariar los paquetes y servicios: no conviene ejecutar a ciegas comandos como rm -rf o borrar una base de datos llamada cloudpanel.

Esta guía se centra en CloudPanel v2 sobre Ubuntu. La documentación oficial consultada describe la instalación, actualización, componentes y copias de seguridad, pero no ofrece un procedimiento universal de desinstalación que devuelva cualquier servidor a su estado original.

Qué significa realmente desinstalar CloudPanel

Hay tres objetivos distintos y conviene elegir el correcto antes de tocar APT:

• Retirar solo el paquete CloudPanel: elimina el paquete que APT tenga registrado con ese nombre y sus archivos de configuración gestionados por el sistema de paquetes, pero pueden quedar servicios, dependencias, archivos generados y configuraciones del servidor.
• Dejar de usar el panel y conservar los sitios: requiere migrar o administrar manualmente NGINX, PHP, bases de datos, certificados, usuarios, tareas programadas y demás componentes. No es una desinstalación automática.
• Eliminar CloudPanel y recuperar un servidor limpio: implica respaldar y sacar los datos del VPS y luego reinstalar el sistema operativo desde el proveedor. La reconstrucción borra el contenido del disco que se vuelva a crear.

Antes de decidir qué conservar, identificá qué servicios, sitios y bases de datos utiliza realmente tu instalación. La documentación oficial de bases de datos de CloudPanel explica cómo exportar e importar bases y dónde se guardan las copias automáticas.

Antes de empezar: hacé una copia que puedas restaurar

No empieces con apt purge, borrado de directorios ni eliminación de bases de datos hasta tener una copia externa. Un snapshot del proveedor ayuda a volver atrás ante un fallo, pero no reemplaza una copia independiente de los datos que necesitás conservar.

1. Respaldá los archivos de cada sitio

Identificá todos los dominios, usuarios de sitio y directorios de trabajo. Guardá los archivos web, configuraciones de NGINX o virtual hosts, certificados, claves que debas conservar, tareas cron y archivos de configuración personalizados. Copiá los respaldos fuera del servidor: una copia guardada únicamente en el VPS se pierde si lo reconstruís.

Si utilizás una función de backups remotos del panel, revisá en tu propia instancia qué directorios incluye, cuáles excluye y en qué destino almacena los archivos. No supongas que una copia automática contiene todos los datos, certificados o configuraciones que necesitás para reconstruir el servidor.

2. Exportá las bases de datos

CloudPanel documenta la exportación mediante clpctl db:export. Se ejecuta con el usuario del sitio, no copiando una orden genérica de MySQL con credenciales inventadas.

cd ~/tmp/
clpctl db:export --databaseName=MI_BASE --file=MI_BASE.sql.gz

Reemplazá MI_BASE por el nombre real de cada base. Comprobá que el archivo se haya creado, que tenga un tamaño razonable y que puedas leerlo o restaurarlo en un entorno de prueba. La documentación oficial de bases de datos explica el procedimiento y la importación.

CloudPanel también informa que genera copias de las bases de datos cada noche a las 03:15, con una retención de siete días, dentro de /home/<usuario-del-sitio>/backups/. No dependas exclusivamente de ese historial: descargá los archivos que necesites y conservá una copia fuera del VPS.

3. Registrá la configuración que no querés perder

• Dominios y registros DNS, incluidos los subdominios.
• Usuarios de sistema y usuarios de bases de datos.
• Versiones de PHP asignadas a cada sitio.
• Certificados TLS y método de renovación.
• Reglas de firewall, puertos y listas de IP permitidas.
• Tareas cron, procesos Node.js o Python y servicios adicionales.
• Configuraciones personalizadas de NGINX, PHP, MySQL o MariaDB.

Antes de continuar, verificá que los archivos y los dumps SQL estén fuera del servidor y que exista un procedimiento de restauración. Si no podés recuperar un sitio desde la copia, todavía no es momento de desinstalar.

Identificar qué versión y qué componentes están instalados

Conectate por SSH con una cuenta que tenga permisos administrativos. Primero identificá la distribución y confirmá si el paquete cloudpanel está instalado:

cat /etc/os-release
dpkg-query -W -f='${Status} ${Version}\n' cloudpanel

Si la segunda orden devuelve install ok installed, el paquete figura como instalado en la base de datos de dpkg. Si informa que no encuentra el paquete, no ejecutes una purga a ciegas: puede tratarse de otra versión, una instalación incompleta o restos de una instalación anterior.

Para conocer los archivos registrados por el paquete y sus dependencias, consultá:

dpkg -L cloudpanel
apt-cache depends cloudpanel

dpkg -L muestra los archivos que el paquete declara instalar, pero no necesariamente todos los archivos que se generaron durante la configuración o el funcionamiento. Por eso, no uses esa lista como autorización para borrar directorios completos.

También podés revisar las unidades de servicio existentes antes de detener nada:

systemctl list-unit-files --type=service | grep -Ei 'cloudpanel|clp|nginx|mysql|mariadb|redis|php|proftpd|varnish'

El resultado sirve como inventario. No detengas NGINX, PHP-FPM, MySQL/MariaDB ni otros servicios si todavía alojan sitios activos. Tampoco des por hecho que existe una unidad llamada cloudpanel.service: verificá el nombre real en ese servidor.

Opción 1: retirar solamente el paquete CloudPanel

Esta alternativa es para administradores que entienden qué servicios van a conservar y quieren quitar el paquete de la instalación. No equivale a una limpieza completa ni restaura automáticamente la configuración anterior del sistema.

1. Simulá la operación antes de ejecutarla

APT permite simular una purga sin modificar el sistema:

sudo apt-get -s purge cloudpanel

Revisá toda la salida. La simulación debe servir para entender qué paquetes propone quitar. Si aparecen NGINX, MySQL/MariaDB, PHP, Redis u otros componentes que usan tus sitios, no confirmes la operación hasta saber por qué se incluirían y qué impacto tendría.

La opción -s equivale a una simulación: no cambia el sistema ni prueba que los scripts internos del paquete vayan a terminar correctamente durante una purga real. La diferencia entre quitar y purgar un paquete está explicada en el manual de apt-get de Ubuntu.

2. Ejecutá la purga solo si el plan es aceptable

Si confirmaste que el paquete está instalado, tenés un snapshot restaurable y revisaste que APT no vaya a retirar componentes necesarios, podés iniciar la purga interactiva:

sudo apt purge cloudpanel

Leé el resumen que muestra APT antes de aceptar. No agregues -y: en un servidor de producción necesitás revisar la lista de paquetes y confirmar conscientemente cada cambio.

La purga elimina el paquete y los archivos de configuración que administra el sistema de paquetes. No garantiza que desaparezcan todas las dependencias, los servicios de la pila web, las bases de datos, los sitios ni los archivos creados fuera del paquete.

3. Si APT devuelve un error, detenete

Los scripts de mantenimiento de un paquete pueden fallar por el estado de APT, dependencias o particularidades de la instalación. Si aparece un error, no intentes forzar la eliminación ni borrar archivos internos de dpkg: conservá la salida completa y revisá los registros antes de continuar.

Si aparece un error de dpkg, guardá la salida completa y revisá los registros:

sudo tail -n 100 /var/log/apt/history.log
sudo tail -n 100 /var/log/dpkg.log

No intentes resolverlo borrando a mano archivos de /var/lib/dpkg/info/, usando opciones --force o ejecutando comandos de eliminación recursiva encontrados en foros. Podrías dejar el sistema de paquetes inconsistente. Conservá el snapshot y consultá el soporte o la comunidad oficial de CloudPanel con el error exacto.

Opción 2: eliminar CloudPanel por completo mediante una reconstrucción del VPS

Si tu objetivo es dejar atrás CloudPanel, instalar otro panel o recuperar un Ubuntu limpio, esta suele ser la ruta más previsible. La documentación de CloudPanel pide un servidor vacío para instalar el panel. Además, en una incidencia de julio de 2026 sobre CloudPanel 2.5.4 en Ubuntu 26.04, el propietario del proyecto indicó que para reinstalar CloudPanel se necesita un servidor en blanco.

Eso no significa que debas reconstruir el VPS sin preparar la migración. La reconstrucción elimina los datos del disco que se vuelve a crear, por lo que el orden importa:

1. Exportá los sitios y las bases de datos. Guardá los archivos, dumps SQL, certificados y configuraciones que vayas a reutilizar.
2. Copiá todo fuera del VPS. Usá almacenamiento remoto o una máquina distinta. No dejes la única copia en el disco que vas a reconstruir.
3. Probá la restauración. Comprobá al menos una base y un sitio en un entorno separado o en el nuevo servidor antes de borrar el anterior.
4. Prepará el destino. Elegí la imagen de Ubuntu y el panel que vas a usar, y verificá los requisitos y el procedimiento de migración de ese producto. Si elegiste CyberPanel como destino, consultá también nuestra guía para actualizar CyberPanel a la última versión antes de ponerlo en producción.
5. Revisá el impacto en el proveedor. Confirmá qué elimina la acción denominada Rebuild, Reinstall o Reimage, y qué ocurre con discos adicionales, IP, snapshots, firewall y claves SSH.
6. Reconstruí el servidor. Ejecutá la acción del proveedor únicamente después de verificar las copias y aceptar que el disco del sistema será reemplazado.
7. Restaurá y probá. Volvé a cargar los sitios, bases, certificados, tareas y reglas necesarias. Cambiá DNS cuando el nuevo entorno esté listo y comprobado.

Antes de instalar otro panel, comprobá sus requisitos de sistema operativo, versiones de base de datos y servicios. No reutilices automáticamente configuraciones del servidor anterior: pueden ser incompatibles con el nuevo entorno.

Comandos y acciones que no conviene copiar sin verificar

La guía original de WebHostingGeeks propone detener un servicio llamado cloudpanel, purgar el paquete, borrar /etc/cloudpanel y /var/www/cloudpanel, y eliminar una base de datos y un usuario llamados cloudpanel. Esos pasos no deben tomarse como universales para cualquier instalación actual de CloudPanel v2.

No asumas que existe cloudpanel.service

La pila de CloudPanel está formada por varios servicios. La documentación oficial enumera NGINX, motores de base de datos, versiones de PHP, Redis, ProFTPD, Node.js, Python y Varnish, entre otros componentes. Detenerlos indiscriminadamente puede dejar fuera de servicio los sitios que todavía necesitás.

No borres rutas por el nombre del panel

Las rutas /etc/cloudpanel y /var/www/cloudpanel aparecen en la guía de referencia, pero no son una prueba de que todos los archivos de una instalación v2 estén ahí. Un reporte del repositorio oficial muestra, por ejemplo, archivos de la aplicación en /home/clp/htdocs/app/files para un caso concreto de CloudPanel 2.5.4. Esa ruta tampoco debe convertirse en una ruta universal.

Usá dpkg -L cloudpanel y revisá la configuración real. No ejecutes rm -rf sobre directorios de sitios, bases de datos o servicios sin identificar antes qué contienen y quién los utiliza.

No elimines una base de datos por su nombre supuesto

CloudPanel permite crear bases y usuarios para cada sitio. La documentación oficial explica cómo exportarlos y administrarlos. No hay que asumir que todas las instalaciones tienen una base llamada cloudpanel o un usuario SQL con el mismo nombre. Antes de borrar una base, identificá su contenido, dependencias y copia de seguridad. Si no podés confirmar esos datos, no la elimines.

No ejecutes autoremove a ciegas

Después de retirar un paquete, APT puede sugerir dependencias que considera innecesarias. En un servidor web, alguna de ellas puede seguir siendo utilizada por otro servicio o aplicación. Si evaluás limpiar dependencias, simulá también esa operación y revisá paquete por paquete antes de confirmarla:

sudo apt-get -s autoremove --purge

No ejecutes la limpieza real si la lista incluye componentes que necesitás. El objetivo es retirar CloudPanel, no desinstalar accidentalmente la pila que mantiene tus sitios en línea.

Cómo comprobar el estado del servidor después del cambio

Si solo retiraste el paquete, revisá el estado de los servicios que decidiste conservar. No alcanza con comprobar que el panel ya no responde en el puerto 8443: también hay que confirmar que los sitios y sus bases de datos continúan funcionando.

• Comprobá el estado de NGINX y del motor de base de datos que uses.
• Verificá las versiones y servicios PHP-FPM asignados a los sitios.
• Probá cada dominio por HTTPS y revisá los certificados.
• Comprobá tareas cron, procesos Node.js o Python y conexiones FTP/SFTP que sigan siendo necesarias.
• Revisá los registros de servicios y los errores de APT o dpkg.
• Confirmá que las copias externas siguen accesibles y que podés restaurarlas.

Si reconstruiste el VPS, repetí estas pruebas después de restaurar cada aplicación. No cambies todos los DNS al mismo tiempo que empezás la restauración: primero validá el nuevo entorno y luego trasladá el tráfico de forma controlada.

Preguntas frecuentes sobre la desinstalación de CloudPanel

¿Alcanza con ejecutar sudo apt purge cloudpanel?

No. Ese comando purga el paquete y su configuración administrada por APT, pero no garantiza que desaparezcan todos los servicios, dependencias, datos y configuraciones creados durante la instalación. Revisá primero la simulación de APT y el contenido del servidor.

¿CloudPanel tiene un desinstalador oficial?

En la documentación oficial consultada para CloudPanel v2 no encontré un procedimiento universal que elimine el panel y restaure automáticamente Ubuntu a su estado previo. Para una retirada completa, la alternativa más previsible es respaldar los datos y reconstruir el VPS.

¿Puedo reinstalar CloudPanel en el mismo Ubuntu después de purgarlo?

No lo des por garantizado. En una incidencia de julio de 2026 sobre CloudPanel 2.5.4, el propietario del proyecto indicó que la reinstalación requiere un servidor vacío. Si necesitás instalarlo de nuevo, prepará una instancia limpia y revisá los requisitos de la versión que vayas a instalar.

¿La purga de CloudPanel borra mis sitios web?

No se puede asegurar un resultado único para todas las instalaciones: depende de qué archivos y servicios se eliminen y de los scripts del paquete. No confundas purgar el paquete con reconstruir el VPS. Una reconstrucción del disco sí puede borrar los sitios y las bases, por lo que necesitás copias externas antes de iniciarla.

¿Dónde están las copias de las bases de datos de CloudPanel?

La documentación de CloudPanel v2 indica que las copias automáticas se guardan en /home/<usuario-del-sitio>/backups/, con una retención predeterminada de siete días. Exportá las bases que necesitás y copiá los archivos fuera del servidor antes de retirar el panel.

¿Qué hago si apt purge cloudpanel falla?

No fuerces la eliminación ni borres archivos de dpkg manualmente. Guardá el error, revisá /var/log/apt/history.log y /var/log/dpkg.log, conservá el snapshot y consultá al soporte o la comunidad de CloudPanel. Los scripts de mantenimiento del paquete pueden fallar en determinados entornos.

Qué método conviene elegir

Si querés quitar únicamente el paquete y conservar Ubuntu, empezá por inventariar la instalación y simular la purga. Confirmá qué componentes siguen prestando servicio a tus sitios y no elimines dependencias sin revisar el impacto.

Si buscás una eliminación completa, vas a cambiar de panel o querés volver a un Ubuntu limpio, respaldá y verificá los datos y reconstruí el VPS desde el proveedor. Es más trabajo de preparación, pero evita convertir una lista de comandos genéricos en una limpieza incompleta o en una caída de los sitios.

Si la migración será hacia CyberPanel y también necesitás revisar el motor de base de datos después del traslado, podés consultar nuestra guía sobre cómo actualizar MariaDB en CyberPanel en 2026. Ese procedimiento es independiente de la migración de los sitios y no reemplaza la exportación e importación de las bases.

Documentación y referencias

• CloudPanel: exportación, importación y copias de bases de datos
• Ubuntu: manual de apt-get y modo de simulación
• CloudPanel CE: respuesta del mantenedor sobre reinstalación en servidor limpio, julio de 2026