Marketplace

Elija un VPS Cloud y luego seleccione la plantilla deseada: el entorno se instala automáticamente y es accesible desde su dominio.

El Marketplace es un catálogo de plantillas VPS: aplicaciones de código abierto preconfiguradas que despliega en su VPS en unos pocos clics.

No. Se trata de software de código abierto que ofrecemos en forma de plantillas listas para desplegar. Usted paga el VPS que las aloja, no el software.

Las aplicaciones ofrecidas son de código abierto y gratuitas. Su único costo es el del VPS Cloud en el que se ejecutan.

El catálogo abarca la IA, la automatización, las bases de datos, los CMS, el despliegue y mucho más (142 soluciones hasta la fecha). Se amplía con regularidad.

Sí. A través del formulario de contacto, elija «Sugerir una solución» e indique la aplicación de código abierto que desea, así como su caso de uso.

La configuración mínima de una aplicación se entiende sobre un servidor libre. Ahora bien, sus aplicaciones ya instaladas consumen una parte de la RAM, de la CPU y del disco: por eso comprobamos el espacio realmente DISPONIBLE en su VPS (y no su capacidad total) antes de lanzar una nueva instalación, para evitar saturar la máquina. Si el espacio libre es insuficiente, aumente los recursos desde su área de cliente (opciones de vCPU / RAM / disco) y vuelva a lanzar la instalación — o desinstale una aplicación que haya dejado de serle útil.

Para garantizar una instalación que funcione a la primera, comprobamos la compatibilidad con lo que ya está instalado en su servidor. Una aplicación aparece bloqueada en tres casos: (1) «conflicto de puerto» — necesita el mismo puerto de red que una aplicación ya presente (dos servicios no pueden escuchar en el mismo puerto de un servidor); (2) «conflicto» — se trata de un rol que solo puede existir en un único ejemplar, por ejemplo dos reverse-proxies como Caddy y HAProxy que quieren gestionar ambos los puertos 80/443; (3) «requisito previo» — necesita que otra aplicación esté instalada antes. En cada caso, el motivo se muestra debajo de la aplicación. Para instalarla de todos modos: desinstale la aplicación en conflicto, instale primero el requisito previo o utilice otro VPS.

Gitea es una plataforma Git de código abierto y ligera escrita en Go. El autoalojamiento le ofrece repositorios privados ilimitados, un CI/CD integrado (Gitea Actions), un registro de paquetes y permisos de equipo detallados — todo ello en un VPS de 2 GB de RAM, sin facturación por usuario.

Gitea sirve su interfaz web en el puerto 3000 (redirigido hacia 80/443 mediante Caddy o Nginx). Git por SSH se expone en el puerto 2222 para evitar cualquier conflicto con el SSH del host VPS en el puerto 22.

Sí. Active Gitea Actions en su app.ini (`[actions] ENABLED = true`) y registre un contenedor `act_runner` en el mismo VPS. Gitea Actions es compatible con la sintaxis YAML de GitHub Actions, de modo que la mayoría de los flujos de trabajo existentes funcionan sin modificación.

Utilice `git clone ssh://git@<your-domain>:2222/<user>/<repo>.git`. También puede añadir un bloque Host en `~/.ssh/config` para definir Port 2222 de forma transparente, de modo que los comandos Git estándar funcionen sin especificar el puerto.

Gitea funciona con comodidad en un VPS con 1 vCPU y 2 GB de RAM para equipos de hasta 20 usuarios. Añada más RAM si activa runners locales de Gitea Actions que compilen código. Prevea al menos 20 GB de almacenamiento SSD según el volumen de repositorios.

PocketBase es un backend-as-a-service (BaaS) de código abierto escrito en Go. Reúne una base de datos SQLite integrada, una API REST y WebSocket en tiempo real, una autenticación integrada (correo/contraseña, OAuth2, OTP) y un panel de administración web en un único binario — sin servidor de base de datos externo ni archivos de configuración.

PocketBase funciona con 512 MB de RAM para cargas ligeras. Un VPS de 1–2 GB gestiona cómodamente miles de usuarios activos al día. Aumente los recursos únicamente si procesa archivos muy grandes o ejecuta en paralelo tareas en segundo plano con alto consumo de cálculo.

PocketBase es mucho más ligero (un único binario frente a más de 10 servicios Docker en el caso de Supabase) y tiene un coste de VPS fijo, sin facturación por lectura o por escritura. Firebase y Supabase se adaptan mejor a un escalado en la nube ilimitado; PocketBase se adapta mejor a las aplicaciones con coste previsible, por debajo de aproximadamente 1 M de peticiones al día.

PocketBase admite Google, GitHub, GitLab, Apple, Twitter/X, Facebook, Microsoft, Spotify, Kakao, Twitch y otros. Actívelos en el panel de administración, en Settings → Auth Providers, pegando su client ID y su secreto OAuth2.

Todos los datos residen en el volumen Docker `/pb/pb_data` — un archivo SQLite y los archivos subidos. Haga una copia de seguridad de este volumen con `docker run --rm -v pocketbase:/data alpine tar -czf - /data`. PocketBase expone además un endpoint de copia de seguridad integrado, accesible desde el panel de administración.

Sí. PocketBase admite hooks JavaScript desde la v0.17: ejecute código antes o después de los eventos de creación, actualización, eliminación de registros o de autenticación. Para casos de uso avanzados, integre PocketBase como biblioteca Go y añada sus propios handlers HTTP o tareas en segundo plano.

Vaultwarden es una implementación de código abierto no oficial del servidor Bitwarden, escrita en Rust. Es 100 % compatible con todos los clientes oficiales de Bitwarden (extensiones de navegador, iOS, Android, escritorio, CLI) y consume menos de 50 MB de RAM — lo que la hace ideal para el autoalojamiento en un VPS pequeño.

Sí. Los clientes oficiales de Bitwarden se niegan a conectarse a un servidor que no tenga un certificado TLS válido. Necesita un nombre de dominio y un proxy inverso (Caddy, Nginx o Traefik) con un certificado Let's Encrypt. Caddy lo reduce a una sola línea — provisiona y renueva el certificado automáticamente a partir de su Caddyfile.

Vaultwarden consume menos de 50 MB de RAM en reposo. Un VPS de 512 MB basta para un uso personal o un equipo pequeño; 1 GB resulta cómodo para una organización de 20–50 usuarios. Se ejecuta sin dificultad junto a otros servicios sin afectar al rendimiento.

Sí. Exporte su caja fuerte desde Bitwarden.com (Settings → Export Vault → JSON format) e impórtela en la caja fuerte web de Vaultwarden, en Tools → Import Data. La operación tarda menos de dos minutos y conserva todas las contraseñas, carpetas, notas e identidades.

Defina la variable de entorno `SIGNUPS_ALLOWED=false` en el contenedor y reinícielo. Los nuevos registros serán rechazados. Siempre podrá invitar a usuarios concretos desde el panel de administración, que se activa con la variable de entorno `ADMIN_TOKEN`.

Todos los datos residen en el volumen Docker `/data`: un archivo SQLite y los archivos adjuntos. Ejecute `docker run --rm -v vaultwarden:/data -v /backup:/out busybox tar czf /out/vaultwarden-backup.tar.gz /data` para crear una instantánea. Programe este comando en cron para obtener copias de seguridad diarias automáticas.

Beszel es un hub de supervisión de servidores ligero y de código abierto (MIT). Usted despliega un único hub e instala pequeños agentes en cada servidor que quiera supervisar. El hub agrega en tiempo real las métricas de CPU, RAM, disco, ancho de banda y contenedores Docker de todos sus servidores en un único panel basado en PocketBase.

En reposo, el hub consume menos de 50 MB de RAM y cabe sin problema en un VPS de 512 MB junto a otros servicios. Los agentes son aún más ligeros: unos pocos MB cada uno. Puede supervisar más de 20 servidores sin que el hub supere los ~100 MB de RAM.

No. Los agentes Beszel establecen conexiones salientes hacia el hub — los servidores supervisados no necesitan ningún puerto entrante abierto. Basta con que el puerto 8090 (o el puerto de su proxy HTTPS) sea accesible en el propio servidor del hub.

Uptime Kuma está diseñado para los controles de disponibilidad: ¿una URL o un puerto TCP está activo o fuera de servicio? Beszel está diseñado para la supervisión de recursos: CPU, RAM, disco, ancho de banda y estadísticas de Docker por servidor. Son complementarios — utilice Uptime Kuma para las sondas externas de caja negra y Beszel para las métricas internas de todo su parque.

Sí. Monte `/var/run/docker.sock` al iniciar el contenedor del agente y Beszel descubre y sigue automáticamente todos los contenedores Docker de ese host — CPU, RAM y red por contenedor, sin exportador adicional.

Beszel admite email, Telegram, Slack, Discord, ntfy, PagerDuty y Pushover mediante sus ajustes de notificación integrados. Defina un umbral en cualquier métrica (p. ej. disco > 80 %) y Beszel dispara la alerta cuando se supera el umbral, y de nuevo cuando vuelve a situarse por debajo.

Twenty es un CRM de código abierto (AGPL-3.0) concebido como una alternativa autoalojada a Salesforce y HubSpot. Ofrece objetos y campos personalizables, vistas kanban y de lista, una API GraphQL + REST, notas y tareas integradas, y un worker en segundo plano para las automatizaciones y los webhooks. Desde la v2.1.0, está listo para producción en despliegues autoalojados monoinquilino.

La pila Twenty completa (server + worker + PostgreSQL + Redis) consume alrededor de 1,2 GB de RAM en reposo. Prevea 2 GB como mínimo y 4 GB recomendados para dejar a PostgreSQL margen bajo consultas concurrentes. El server por sí solo utiliza aproximadamente 300–400 MB en reposo.

Sí — Twenty es totalmente de código abierto bajo licencia AGPL-3.0. El autoalojamiento en su propio VPS es gratuito. Ningún coste por usuario, ninguna facturación por uso y ninguna funcionalidad bloqueada tras un plan de pago en la edición autoalojada. Usted solo paga el VPS.

HubSpot y Salesforce son productos SaaS en la nube facturados por usuario, con sus datos almacenados en la infraestructura de estos proveedores. Twenty es autoalojado: todos los datos permanecen en su servidor, el coste es una tarifa fija de VPS y usted puede ampliar el esquema, la API y las automatizaciones sin aprobación del proveedor ni restricciones de marketplace.

Sí: todos los objetos de Twenty (contactos, empresas, oportunidades y cualquier objeto personalizado que usted defina) son accesibles a través de una API GraphQL totalmente documentada y una API REST. Los webhooks se activan con cualquier evento de registro. La API es la superficie de integración principal, no una idea de última hora.

Sí. Twenty admite la importación CSV desde los ajustes del espacio de trabajo → Importar. Exporte sus contactos y empresas en formato CSV desde HubSpot, Pipedrive o cualquier CRM antiguo y, a continuación, impórtelos en el objeto de Twenty correspondiente. Las migraciones más complejas (negocios con historial de actividad) pueden requerir un breve script de API.

Qdrant es una base de datos vectorial de código abierto escrita en Rust. Almacena fragmentos de documentos en forma de vectores de embedding y recupera los más similares en unos milisegundos. El RAG (Retrieval-Augmented Generation) lo utiliza para inyectar contexto pertinente en cada llamada al LLM, de modo que su IA responda a partir de hechos en lugar de alucinar. Una base de datos relacional o un índice de texto completo no puede igualar la velocidad ni la precisión de Qdrant en esta tarea.

En reposo, Qdrant consume aproximadamente 100–200 MB de RAM. El límite práctico es el tamaño de su índice: 1 millón de vectores float32 de 1536 dimensiones ocupan alrededor de 6 GB sin cuantificación, o ~1,5 GB con una cuantificación escalar (int8). Para la mayoría de los proyectos RAG de tamaño pequeño a mediano, un VPS de 4 GB constituye un punto de partida cómodo.

Cualquier modelo que produzca vectores float de tamaño fijo. Opciones autoalojadas populares vía Ollama: mxbai-embed-large (1024 dims), nomic-embed-text (768 dims). Vía API: OpenAI text-embedding-3-small (1536 dims), Cohere Embed. LangChain, LlamaIndex, Haystack y los SDK oficiales de Qdrant (Python, TypeScript, Go, Rust) disponen todos de conectores nativos.

Sí. Ambos se despliegan en un único contenedor, sin conflicto de puertos (Ollama en 11434, Qdrant en 6333/6334). Un VPS de 4 GB de RAM ejecuta los dos sin dificultad con un modelo 7B Q4 cargado — lo que le ofrece una pila RAG totalmente autónoma y aislada de la red: embedding con Ollama, recuperación con Qdrant, generación con Ollama, sin ninguna API externa.

Sí. Qdrant es la principal alternativa autoalojada a Pinecone. Iguala o supera a Pinecone en latencia y en recall en los benchmarks, admite el mismo ecosistema de modelos de embedding y cuesta una tarifa fija de VPS en lugar de una facturación por vector y por consulta. La contrapartida: usted gestiona la infraestructura por su cuenta.

Reinicie el contenedor definiendo la variable de entorno QDRANT__SERVICE__API_KEY con una cadena aleatoria robusta. Todas las peticiones REST y gRPC deben incluir entonces la cabecera `api-key`. Coloque Qdrant detrás de Caddy o Nginx para el HTTPS. No exponga nunca el puerto 6333 a Internet sin autenticación.

Infisical es un gestor de secretos de código abierto (MIT, 27,6k estrellas) — una alternativa autoalojada a Doppler y HashiCorp Vault. Centraliza las claves de API, las contraseñas de bases de datos y los certificados en una sola bóveda, sincronizados automáticamente hacia sus aplicaciones y sus pipelines de CI mediante SDK e integraciones nativas. El autoalojamiento mantiene sus credenciales más sensibles en su propia infraestructura con registros de auditoría completos, por un costo fijo de VPS en lugar de una facturación SaaS por desarrollador.

La pila Infisical (aplicación + PostgreSQL 14 + Redis) consume unos 600–800 MB de RAM en reposo y supera 1 GB en los picos, bajo peticiones API concurrentes procedentes de varias aplicaciones. Prevea un VPS con al menos 2 GB de RAM (4 GB recomendados para equipos con varios servicios que recuperan secretos simultáneamente).

Sí. Infisical ofrece integraciones CI/CD de primer nivel: GitHub Actions (acción oficial en el marketplace), GitLab CI (sincronización nativa de las variables), CircleCI y Jenkins. Usted añade un service token como secreto de CI y, a continuación, la integración inyecta los secretos del entorno correcto directamente en cada ejecución del pipeline — ningún archivo .env, ninguna rotación manual.

Sí. Instale el SDK de Infisical (`npm install @infisical/sdk` o `pip install infisical-python`) y recupere los secretos al arrancar. También puede utilizar el wrapper de la CLI: `infisical run -- node server.js` inyecta los secretos como variables de entorno, de modo que su aplicación los lee mediante `process.env` — sin integrar el SDK y sin que ningún secreto toque jamás el sistema de archivos.

Sí. Infisical cifra en reposo cada valor de secreto con AES-256-GCM mediante una `ENCRYPTION_KEY` que usted genera y controla. En tránsito, todas las comunicaciones se realizan por HTTPS. El acceso se rige por políticas basadas en roles, service tokens e identidades de máquina que aplican el principio de mínimo privilegio. Cada lectura y cada escritura queda consignada en el registro de auditoría. El núcleo MIT incluye todas estas funciones de seguridad — no se requiere ningún plan de pago.

Resuelven problemas distintos: Vaultwarden es un gestor de contraseñas personal y de equipo (compatible con Bitwarden — credenciales de inicio de sesión humanas, extensiones de navegador, aplicaciones móviles). Infisical es un gestor de secretos para las máquinas y el código (claves API, URI de bases de datos, tokens — consumidos por programa por las aplicaciones y los pipelines CI/CD mediante SDK o la CLI). La mayoría de los equipos utilizan ambos: Vaultwarden para las credenciales humanas, Infisical para los secretos de las aplicaciones.

Dockge es un gestor visual de código abierto (MIT) de stacks Docker Compose, creado por Louis Lam — el desarrollador que está detrás de Uptime Kuma. Le permite crear, modificar, iniciar, detener y supervisar todas sus aplicaciones multicontenedor desde una interfaz web depurada en el puerto 5001, sin SSH ni línea de comandos. Almacena cada stack en forma de archivo `compose.yaml` estándar en `/opt/stacks` de su host.

Dockge consume en reposo menos de 150 MB de RAM y cabe en cualquier VPS sin afectar a los demás servicios que se ejecutan en él. Se basa en Node.js con una base de datos SQLite — ninguna base de datos ni caché externa que aprovisionar. Un VPS de 512 MB puede ejecutar Dockge cómodamente junto a varias stacks gestionadas.

Sí. Coloque sus archivos `compose.yaml` existentes en subdirectorios dentro de `/opt/stacks` (por ej. `/opt/stacks/n8n/compose.yaml`) y Dockge los detectará y los mostrará automáticamente en la próxima carga. La convención de ruta es `<stacks-dir>/<stack-name>/compose.yaml` — cualquier stack que ya siga esa disposición aparece en la interfaz sin ningún paso de importación.

Cubren ámbitos diferentes: Dockge es un gestor de Compose puro — le permite crear y gestionar stacks en el propio servidor donde se ejecuta. Coolify y Dokploy son plataformas PaaS completas con integración Git, SSL automático, promoción de entornos y despliegues multiservidor. Use Dockge cuando quiera una interfaz ligera para sus stacks hechas a mano; use Coolify o Dokploy cuando quiera despliegue por git-push y SSL automatizado listos para usar.

La consola de terminal integrada se desactivó por defecto en la v1.5.0 a raíz de un aviso de seguridad (GHSA-7vx4-hf96-mqq6). El resto de Dockge — gestión de stacks, streaming de registros, panel de estado — es plenamente funcional sin la consola. No la active en una instancia expuesta públicamente. Si necesita acceso shell a los contenedores, utilice más bien una sesión SSH dedicada.

Abra la stack en la interfaz de Dockge, haga clic en Update y luego en Start. Entre bastidores, Dockge ejecuta `docker compose pull` seguido de `docker compose up -d`. Para actualizar el propio Dockge, edite su `compose.yaml` (en `/opt/dockge` o allí donde lo haya instalado), cambie la etiqueta de la imagen si es necesario y ejecute `docker compose up -d` desde el terminal — o utilice otra instancia de Dockge para gestionarlo.

Authelia es una pasarela de autenticación y autorización de código abierto (Apache 2.0). Se sitúa delante de sus aplicaciones como punto de terminación forward-auth en su reverse proxy (Nginx, Caddy, Traefik). Cada petición se verifica con respecto a su política: los usuarios no autenticados son redirigidos al portal de conexión de Authelia, donde puede imponer una contraseña, TOTP, passkeys o cualquier combinación. Las propias aplicaciones no necesitan ninguna modificación — Authelia las protege a nivel de infraestructura.

Sí. Las cookies de sesión de Authelia deben estar limitadas a un dominio (`Domain=.yourdomain.com`), y los callbacks OIDC así como los certificados Let's Encrypt exigen un FQDN resoluble públicamente en HTTPS. Authelia no puede funcionar correctamente detrás de una simple dirección IP. Cuando lo despliega a través de ServOrbit, apunte un registro A a su VPS e introduzca el dominio durante la configuración — el reverse proxy y el certificado TLS se configuran automáticamente.

Authelia en sí consume en reposo menos de 30 MB de RAM. Añada unos 20 MB para el almacén de sesiones Redis. Total: menos de 60 MB para la pila de autenticación completa. Un VPS de 512 MB basta para un uso personal; 1 GB resulta cómodo para un equipo de 20 usuarios o más.

Sí. Authelia es un proveedor OpenID Connect (OIDC) certificado. Registre cada aplicación como cliente OIDC en `configuration.yml` — asígnele un client ID, un secreto y una redirect URI. Configure después la aplicación para que utilice Authelia como proveedor de identidad. Los usuarios se autentican una sola vez en su portal de autenticación y son transferidos de forma silenciosa a cada aplicación conectada sin tener que volver a introducir sus credenciales.

Authelia admite TOTP (cualquier aplicación de autenticación: Google Authenticator, Ente Auth, Aegis, Bitwarden Authenticator), WebAuthn/Passkeys (Touch ID, Face ID, YubiKey, cualquier llave de hardware FIDO2) y las notificaciones push de Duo. Los usuarios pueden registrar varios métodos y elegir en el momento de iniciar sesión. El MFA se impone por dominio, por grupo o de forma global, según sus reglas de control de acceso.

Actual Budget es una aplicación de finanzas personales de código abierto (MIT), local-first, basada en la presupuestación de base cero (método de los sobres). Es una alternativa autoalojada a YNAB — usted ejecuta un servidor Node.js ligero en su propio VPS y sincroniza su presupuesto con cualquier dispositivo gracias al cifrado de extremo a extremo. Sus datos financieros nunca salen de su infraestructura.

La metodología de presupuesto es idéntica: asigne cada dólar a un sobre (categoría) con nombre antes de gastarlo. Las diferencias: Actual tiene licencia MIT sin cuota de suscripción, sus datos permanecen en su propio servidor y el código fuente es totalmente auditable en GitHub. YNAB dispone de una aplicación móvil nativa más cuidada; Actual ofrece una PWA rápida y una comunidad de código abierto activa.

El servidor Node.js consume en reposo menos de 80 MB de RAM. Un VPS de 1 GB es de sobra suficiente para varios usuarios simultáneos. Actual Budget es una de las herramientas de finanzas autoalojadas más económicas en recursos que existen.

Sí, mediante dos integraciones opcionales: GoCardless para los bancos europeos (API de open banking, sin compartir credenciales) y SimpleFIN para los bancos norteamericanos. Si su banco no es compatible, puede importar archivos OFX, QFX, QIF o CSV exportados desde su portal de banca en línea. La introducción manual de las transacciones también funciona muy bien para mantener el control de su tesorería.

Sí. Todos los datos se almacenan en un archivo SQLite en su VPS y se sincronizan entre los dispositivos mediante cifrado de extremo a extremo — el servidor solo manipula texto cifrado y nunca lee sus transacciones ni sus saldos. Ningún servicio de terceros tiene acceso a sus registros financieros.

Sí. Actual admite la importación directa desde YNAB 4 (exportación local) y nYNAB (exportación web). Sus categorías, cuentas, importes presupuestados y el historial de transacciones se conservan íntegramente. La migración tarda unos cinco minutos, directamente desde la pantalla de ajustes de Actual Budget.

Umami es una herramienta de analítica web de código abierto (licencia MIT) autoalojada que mide su audiencia sin cookies ni recopilación de datos personales. A diferencia de Google Analytics 4, Umami no necesita banner de consentimiento (sin cookies → sin obligación RGPD), el script de seguimiento pesa menos de 2 KB y se sirve desde su propio dominio. Sus datos permanecen en su VPS y nunca transitan por un servidor de terceros.

No hay ningún límite. Una sola instancia de Umami puede medir un número ilimitado de sitios web. Cada sitio recibe su propio identificador de seguimiento y sus propias claves API, lo que permite delimitar los accesos por sitio (útil para las agencias que gestionan varios clientes). El consumo de recursos aumenta ligeramente con el volumen de eventos, pero de 1 a 2 GB de RAM bastan para decenas de sitios con tráfico moderado.

De forma predeterminada, el script es accesible en `/script.js` en su dominio. La mayoría de los bloqueadores de publicidad no apuntan a los nombres de archivo genéricos en dominios first-party, por lo que Umami suele pasar allí donde Google Analytics y Plausible quedan bloqueados. Si necesita una protección adicional, defina la variable de entorno `TRACKER_SCRIPT_NAME` en su archivo Docker Compose para renombrar el script con algo neutro (p. ej. `u`), lo que lo vuelve prácticamente invisible para las listas de filtros.

Sí. Umami ofrece una API de eventos sencilla en JavaScript: llame a `umami.track(nombreEvento, datos)` en cualquier punto de su código, por ejemplo `umami.track('clic_registro', { plan: 'pro' })`. Los eventos aparecen en el panel de control, en la pestaña Eventos. Ningún gestor de etiquetas, ningún tag de Google — solo una llamada de función y sus propios datos en su servidor.

Sí. La versión de código abierto de Umami (licencia MIT) es totalmente gratuita, sin ninguna limitación de funcionalidades. Umami ofrece también un plan Cloud gestionado de pago en umami.is, pero en ServOrbit usted solo paga el VPS — Umami en sí no cuesta nada.

DocuSeal es una plataforma de firma electrónica de código abierto (AGPL-3.0, 17 000+ estrellas en GitHub, v3.1.4) que permite crear plantillas PDF, enviar solicitudes de firma a varias partes y recoger firmas digitales jurídicamente válidas — todo ello en su propio servidor. Es una alternativa autoalojada a DocuSign, Adobe Acrobat Sign y HelloSign.

No. DocuSeal utiliza SQLite por defecto — la base de datos es un archivo único almacenado en `/data/db.sqlite3` dentro del contenedor. No se necesita ningún servidor PostgreSQL, MySQL ni Redis. El volumen montado en `/data` conserva todos los documentos y la base de datos entre reinicios del contenedor.

DocuSeal funciona con menos de 256 MB de RAM en reposo. Un VPS de 1 GB resulta cómodo para un equipo que tramita algunas decenas de documentos al mes. Para un volumen elevado o varias sesiones de firma simultáneas, se recomienda un plan de 2 GB.

No. Cada firmante recibe un enlace único (por correo electrónico si SMTP está configurado, o compartido manualmente). Abre el enlace en cualquier navegador, rellena sus campos y lo envía — sin registro ni descarga de aplicación.

DocuSeal genera una pista de auditoría que contiene la dirección de correo electrónico, la dirección IP y la marca de tiempo del firmante para cada firma, así como un certificado de finalización. Esto satisface los requisitos de prueba para las firmas electrónicas simples en el sentido de eIDAS (UE) y de las leyes equivalentes en numerosos países. Para los NDA, contratos y formularios de consentimiento habituales, la pista de auditoría de DocuSeal es suficiente.

Sí. Sin SMTP configurado, DocuSeal funciona por completo — basta con copiar los enlaces de firma desde la página Envíos y compartirlos manualmente (por Slack, WhatsApp o correo electrónico). La aplicación sigue plenamente operativa; SMTP se recomienda para automatizar las invitaciones, los recordatorios y las notificaciones de firma completada.

Changedetection.io es una herramienta de código abierto (Apache 2.0) que vigila cualquier sitio web y le avisa en cuanto una página cambia — precios, existencias, licitaciones, publicaciones oficiales. Funciona en su VPS, sin coste por comprobación.

Sí, mediante un segundo contenedor Playwright/Chromium opcional. Changedetection.io se conecta a él para un renderizado completo de navegador: ideal para los contadores de stock dinámicos, las SPA y las páginas de pago.

Más de 80 canales a través de la biblioteca Apprise: email (SMTP), Telegram, Slack, Discord, ntfy, Gotify, Matrix, webhooks personalizados y muchos más. Puede configurar varios canales por URL supervisada.

Sí. Utilice un selector CSS (p. ej. `.price`), una expresión XPath o un disparador por palabra clave (alerta únicamente si la página contiene o deja de contener un texto determinado). Los filtros eliminan el ruido de los menús, los anuncios y las marcas de tiempo que cambian en cada carga.

El contenedor principal consume menos de 256 MB en reposo. Un VPS de 1 GB basta para vigilar cientos de URL. Con el sidecar Playwright/Chromium para las páginas JS, prevea 2 GB en total.

Sí. Changedetection.io es de código abierto bajo licencia Apache 2.0 — sin límite de URL, sin coste por comprobación, sin cuenta en la nube obligatoria. Usted solo paga el VPS que lo aloja.

Memos es una aplicación de notas de código abierto (MIT) ligera: capture sus ideas, lleve un diario personal o comparta notas con su equipo desde su VPS. Imagen Docker de ~20 MB, menos de 128 MB de RAM, SQLite por defecto.

Memos consume menos de 128 MB de RAM en reposo con SQLite. Su imagen Docker de ~20 MB es una de las más ligeras del catálogo — puede convivir con otras aplicaciones en un VPS de 1 GB sin impacto perceptible.

Sí. Memos ofrece una representación de Markdown en tiempo real en la vista cronológica: negrita, cursiva, bloques de código, casillas de verificación, enlaces e imágenes integradas — todo se representa a medida que escribe. Las capturas de pantalla pegadas directamente también se suben e integran.

Sí. Cada nota se puede cambiar al modo «público» mediante el icono de compartir — obtiene entonces un enlace accesible sin iniciar sesión. El resto de la instancia sigue siendo privado. También es posible hacer pública la instancia completa para un microblog personal.

Sí. Memos expone una API RESTful en /api/v1/ con autenticación por token. Puede publicar notas desde un script, un pipeline CI, un cron job o un bot de Telegram — útil para los registros de standup automáticos o las capturas desde otras herramientas.

Sí. Memos está bajo licencia MIT — libre de usar, modificar y autoalojar. Ninguna suscripción, ninguna telemetría, ninguna cuenta en la nube necesaria. Usted paga únicamente el VPS que lo ejecuta.

Chatwoot es una plataforma de soporte al cliente omnicanal de código abierto (MIT, más de 34 000 estrellas en GitHub, v4.16.0) que centraliza el chat en vivo, los correos, WhatsApp, Telegram, Facebook Messenger y los DM de Twitter/X en una única bandeja de entrada compartida. Autoalojada en su VPS, ofrece una alternativa a Intercom y Zendesk sin coste por agente.

Sí. Chatwoot se integra con la API de WhatsApp Business Cloud (Meta), Twilio WhatsApp y la API de Telegram Bot. Usted conecta cada canal desde el panel Ajustes → Bandejas de entrada. Los mensajes de estos canales aparecen en la bandeja de entrada compartida junto al chat en vivo y los correos electrónicos.

Cree una bandeja de entrada de tipo Sitio web en Ajustes → Bandejas de entrada. Chatwoot genera un snippet JavaScript de dos líneas. Péguelo en el <head> de su sitio: una burbuja de chat personalizable aparece al instante para sus visitantes. El color, el mensaje de bienvenida y el nombre del equipo se pueden configurar desde el panel de control.

Chatwoot funciona con cuatro contenedores Docker (Rails + Sidekiq + PostgreSQL + Redis) que consumen alrededor de 1,2 GB de RAM en reposo. Un VPS de 2 GB de RAM es el mínimo para producción; se recomiendan 4 GB para equipos de más de 10 agentes o con un volumen elevado de conversaciones.

Sí. Chatwoot exige una FRONTEND_URL válida (FQDN en HTTPS) para que las redirecciones OAuth, los enlaces de los correos electrónicos y la URL del script del widget de chat en vivo funcionen correctamente. Sin un dominio, estas funcionalidades (integraciones de correo electrónico, notificaciones, widget) no funcionarán de forma fiable.

Sí. Chatwoot Community Edition es software de código abierto con licencia MIT — gratuito de instalar y de autoalojar con un número ilimitado de agentes. Usted paga únicamente el VPS que lo aloja, no la plataforma. Hay funciones para empresas (SSO, registros de auditoría avanzados, roles personalizados) disponibles en los planes cloud de pago.

Vikunja es un gestor de tareas y proyectos de código abierto y autoalojado (AGPL-3.0, más de 24 k estrellas, v2.4.0). Ofrece vistas de lista, Kanban y Gantt con dependencias, tareas recurrentes, sincronización CalDAV y una API REST completa — una alternativa a Todoist, TickTick y Asana sin cuotas recurrentes.

Vikunja consume menos de 256 MB de RAM en reposo con SQLite como almacenamiento por defecto. La imagen Docker ocupa unos 80 MB. Un VPS de 512 MB puede ejecutar Vikunja con un reverse proxy sin ninguna sobrecarga: un plan de 1 GB ofrece un margen cómodo.

Sí. Vikunja admite la vista de lista, los tableros Kanban con arrastrar y soltar y la vista Gantt con fechas de inicio/fin y dependencias entre tareas. Puede cambiar de vista en cada proyecto sin migrar ningún dato.

Sí. Vikunja expone un endpoint CalDAV/WebDAV en `/dav/`. Cualquier cliente compatible con CalDAV — Thunderbird, DAVx⁵, Apple Reminders — puede conectarse con sus credenciales de Vikunja y sincronizar sus tareas de forma nativa.

Sí. Vikunja incorpora una API REST completa documentada con una especificación Swagger en `/api/v1/docs`. Puede crear, actualizar y cerrar tareas por HTTP con un token de API — útil para los pipelines CI que cierran automáticamente las tareas cuando el despliegue es correcto.

Sí. Vikunja es un software de código abierto con licencia AGPL-3.0 — gratuito de usar y de autoalojar. No hay tarifas por usuario, ni planes de suscripción, ni telemetría. Usted paga únicamente el VPS que lo aloja.

Paperless-ngx es una aplicación de gestión documental (GED) de código abierto y autoalojada (AGPL-3.0, más de 43 k estrellas). Digitaliza sus documentos, les aplica OCR automáticamente mediante Tesseract (francés, inglés, árabe), los indexa a texto completo y los clasifica por corresponsal, tipo y etiquetas — todo en su VPS, sin enviar ningún dato a una nube de terceros.

Sí. La imagen Docker integra Tesseract con los paquetes de idioma completos. La variable `PAPERLESS_OCR_LANGUAGE=fra+eng` — preconfigurada en la receta ServOrbit — activa simultáneamente el OCR en francés, inglés y árabe en cada documento. Los documentos mixtos se procesan correctamente en ambos idiomas.

La stack completa (servidor web Django + PostgreSQL 16 + Redis 7) consume aproximadamente entre 400 y 512 MB de RAM en reposo. Se recomienda un VPS de 2 GB para un uso normal; 4 GB para archivos voluminosos (más de 100 k documentos) o para OCR simultáneos intensivos.

Son dos herramientas complementarias con usos diferentes. Stirling-PDF es una caja de herramientas PDF (50+ operaciones: combinar, dividir, comprimir, convertir, firmar…) — la utiliza para procesar archivos PDF de forma puntual. Paperless-ngx es un sistema de gestión documental de archivo: deposita sus documentos una vez y él los indexa, los clasifica y los hace buscables de por vida. Ambas funcionan muy bien juntas.

Sí. Paperless-ngx expone una REST API completa documentada en `/api/` (Swagger). Puede listar, buscar, descargar, subir y eliminar documentos por HTTP. En n8n, basta con un nodo HTTP Request para desencadenar la ingesta de un archivo adjunto recibido por correo o de un PDF generado por un pipeline de CI.

Sí. Paperless-ngx es un software de código abierto con licencia AGPL-3.0 — gratuito para usar, modificar y autoalojar. Sin coste por documento, sin límite de almacenamiento, sin suscripción. Solo paga el VPS ServOrbit que ejecuta la stack.

NocoBase es una plataforma no-code/low-code de código abierto (Apache-2.0, más de 23 k estrellas) que le permite crear herramientas internas, CRM, flujos de validación y portales de cliente sin escribir código frontend. El principio: usted define colecciones (entidades con campos, relaciones y permisos) y después compone una interfaz con bloques de arrastrar y soltar (tablas, formularios, Kanban, gráficos). Cada colección genera automáticamente una API REST. En ServOrbit, NocoBase se instala en dos contenedores Docker (app + PostgreSQL 16) en un VPS de 2 GB de RAM.

NocoDB transforma cualquier base de datos en una tabla colaborativa al estilo de Airtable — el énfasis está puesto en la visualización de datos existentes en forma de cuadrícula, galería o Kanban sencillo. NocoBase es data-model-first: usted diseña entidades, relaciones, tipos de campos y permisos, y después compone interfaces complejas con bloques (formularios de varios pasos, flujos de trabajo, dashboards). NocoDB destaca para explorar y modificar datos rápidamente; NocoBase está hecho para construir aplicaciones de negocio estructuradas con cadenas de validación, roles granulares y automatizaciones. Ambos están en el catálogo ServOrbit.

Sí. NocoBase se adapta bien a la construcción de un CRM a medida: cree colecciones Contactos, Empresas, Oportunidades y Actividades con relaciones entre ellas. Añada una vista Kanban para el pipeline comercial, un formulario de captación de leads y permisos distintos por equipo (los comerciales ven sus propias oportunidades, los responsables lo ven todo). El motor de workflow puede enviar un correo electrónico automático cuando una oportunidad cambia de estado, o programar recordatorios de seguimiento. Todo permanece en su VPS, exportable mediante CSV o REST API en cualquier momento.

No. NocoBase funciona sin dominio en `http://ip-de-su-vps:13000` para un uso interno o de prueba. Si desea exponer su instancia en internet con HTTPS, apunte un subdominio a su VPS y ServOrbit instalará automáticamente el reverse-proxy nginx + el certificado Let's Encrypt durante el despliegue desde el Marketplace. Para un uso estrictamente interno (equipo conectado por VPN o red local), el puerto 13000 sin dominio es suficiente.

Sí. NocoBase dispone de un gestor de plugins integrado (accesible desde Ajustes → Gestor de plugins). Ofrece más de 80 plugins oficiales: vistas Kanban, Gantt, calendario, gráficos, bloques de mapa, gestor de archivos, flujos de trabajo visuales, importación/exportación Excel, integraciones LDAP/SSO (Enterprise), registros de auditoría, etc. Los plugins se pueden activar sobre la marcha sin reiniciar el servidor. La API de plugin es pública, lo que permite a su equipo desarrollar extensiones a medida si es necesario.

Sí. NocoBase es un software de código abierto con licencia Apache-2.0: gratuito para usar, modificar y autoalojar, sin coste por usuario, sin límite de colecciones y sin telemetría. Existe un plan Enterprise de pago para los equipos que necesitan plugins premium (SSO SAML, registros de auditoría avanzados, marca blanca), pero la edición Community cubre lo esencial para la gran mayoría de los usos. Usted solo paga el VPS ServOrbit que ejecuta la stack.

Glance es un panel de control autoalojado y ligero (AGPL-3.0, ~35 k ⭐, Go). Reúne noticias de Hacker News, feeds RSS, estadísticas del VPS en directo (CPU, RAM, disco) y el estado de sus contenedores Docker en una sola página — un único archivo de configuración YAML, ninguna base de datos, menos de 25 MB de RAM.

No. Glance es totalmente funcional con una dirección IP y un puerto (p. ej. http://95.x.x.x:8080). Un dominio y HTTPS no son obligatorios, pero sí recomendables para la seguridad de las cookies de sesión. Puede añadir un proxy inverso Caddy delante de Glance en cualquier momento.

Edite el archivo /data/glance.yml en el volumen Docker de su VPS. Cada widget es un bloque YAML dentro de la sección columns de una página. Por ejemplo, añada `- type: rss` con una lista de URL para los feeds RSS, o `- type: docker-containers` para ver sus contenedores. Reinicie después Glance (`docker compose restart glance`). La documentación oficial enumera más de 30 tipos de widgets.

No. Glance viene configurado con una autenticación integrada (username/password). Todo visitante es redirigido a una página de inicio de sesión. Puede añadir varios usuarios en la sección auth.users del archivo glance.yml, o situar Glance detrás de una VPN para una protección adicional.

Sí. Añada `- type: docker-containers` en una columna de su glance.yml. El playbook de aprovisionamiento de ServOrbit ya monta /var/run/docker.sock en modo de solo lectura dentro del contenedor Glance. Verá el nombre, la imagen y el estado de cada contenedor activo en el VPS.

Glance permanece en reposo por debajo de 25 MB de RAM, incluso con varios widgets activos. Se trata de un binario Go estático, sin base de datos ni proceso externo. Puede ejecutarlo en un VPS de 512 MB junto a otros servicios (Dozzle, Uptime Kuma) sin saturar la memoria.

Komodo es una plataforma GitOps de código abierto (GPL-3.0) para gestionar stacks Docker y pipelines de despliegue en varios servidores desde un único panel de control. Utiliza una arquitectura Core/Periphery: el Core centraliza la gestión, y unos agentes Periphery ligeros se instalan en cada servidor que se desea pilotar.

Dockge y Portainer son interfaces de gestión de Docker de un solo servidor. Komodo está diseñado para flotas multiservidor: un único Core gestiona un número ilimitado de servidores mediante agentes Periphery. Añade además pipelines GitOps, Procedures automatizados y soporte de Docker Swarm — funcionalidades ausentes en las otras dos.

Sí, se requiere un nombre de dominio (o un subdominio) porque KOMODO_HOST debe apuntar a la URL HTTPS pública de su Core. Esta URL se utiliza para la validación de las firmas HMAC de los webhooks y para las callbacks OAuth. El playbook de ServOrbit configura automáticamente el TLS mediante certbot durante el despliegue.

Instale el agente Periphery en cada nuevo servidor con el comando Docker indicado en la documentación de Komodo (`docker run -d --restart=unless-stopped --network host -v /var/run/docker.sock:/var/run/docker.sock ghcr.io/moghtech/komodo-periphery:2`) y luego añádalo en la interfaz de Komodo mediante Servers → Add Server, indicando su IP y el puerto 8120.

Sí. Configure un webhook en su repositorio de GitHub que apunte a `https://su-dominio.com/api/webhook/komodo`. En Komodo, cree una Procedure con las etapas de despliegue (pull de la imagen, reinicio de la stack, notificación) y vincúlela al webhook. Komodo verifica la firma HMAC antes de ejecutar nada.

El binario Komodo Core (Rust) se mantiene en reposo por debajo de 256 MB de RAM. La base FerretDB + PostgreSQL añade unos 200–300 MB adicionales. Un VPS de 1 GB de RAM es suficiente para el plano de control por sí solo. Los agentes Periphery son aún más ligeros — menos de 50 MB cada uno.

Authelia es un proxy forward-auth ligero que añade MFA delante de sus aplicaciones sin modificarlas — no tiene consola de gestión de usuarios. Authentik es un proveedor de identidad (IdP) completo, con su propio directorio, una consola de administración, SSO mediante OIDC/SAML/LDAP y un editor visual de flujos. Use Authelia para proteger rápidamente aplicaciones existentes; use Authentik cuando necesite un verdadero IdP con gestión del ciclo de vida de las cuentas.

Los contenedores server y worker consumen juntos ~300-400 MB en reposo. PostgreSQL 16 añade ~150 MB. Un VPS de 1 GB es el mínimo estricto; 2 GB es lo recomendado para un uso cómodo. Authentik eliminó su dependencia de Redis a partir de la v2025.10, así que no hay ninguna capa de caché adicional que aprovisionar.

Sí. Las callbacks OIDC, las aserciones SAML y las cookies de sesión requieren HTTPS con un FQDN válido y resoluble públicamente. ServOrbit provisiona automáticamente un certificado TLS mediante Let's Encrypt en cuanto el registro DNS A de su dominio apunta al VPS.

Cualquier aplicación compatible con OIDC/OAuth2 o SAML 2.0. Ejemplos del Marketplace ServOrbit: Gitea, Nextcloud, Mattermost, Docmost, Grafana, Dockge y Metabase. Authentik proporciona integraciones preconstruidas para decenas de aplicaciones populares y permite crear proveedores OIDC/SAML personalizados para cualquier otra aplicación.

Sí. Authentik admite la sincronización desde una fuente LDAP: importe los usuarios desde Active Directory u OpenLDAP con una sincronización programada. Para las importaciones CSV, utilice la API REST o la herramienta de importación masiva de la consola de administración. Los usuarios también pueden registrarse por sí mismos mediante flujos de alta personalizables.

Totalmente. Authentik se utiliza ampliamente en homelabs y en equipos de 2 a 20 usuarios. La edición Community (Apache 2.0) es completa para estos casos de uso. La edición Enterprise añade RBAC avanzado, un SLA de soporte y funcionalidades para grandes organizaciones, pero es totalmente opcional.

Penpot es una herramienta de diseño colaborativo de código abierto (MPL-2.0) autoalojable, mientras que Figma es un SaaS propietario. La diferencia técnica fundamental: Penpot utiliza SVG estándar como formato de archivo nativo, mientras que Figma utiliza un formato binario propietario. En concreto, sus archivos Penpot son legibles por cualquier editor vectorial, exportables y versionables en Git. En el plano funcional, Penpot ofrece el diseño vectorial, los componentes, el prototipado y el handoff para desarrolladores — las mismas funcionalidades básicas que Figma.

El mínimo absoluto es 2 GB de RAM: la stack arranca, pero la exportación de archivos complejos (PDF, PNG de alta resolución) puede saturar el contenedor `penpot-exporter`. La configuración recomendada para un uso en producción es 4 GB de RAM con 2 vCPU. En un VPS ServOrbit de 4 GB, la stack Penpot en reposo consume unos 800 MB, lo que deja margen para sus otros servicios. Para un equipo de más de 10 usuarios activos simultáneamente, prevea 8 GB.

Sí. Penpot importa de forma nativa los archivos `.fig` exportados desde Figma. En un proyecto Penpot, utilice Import → Figma file para seleccionar su exportación. Los frames, componentes, estilos y cuadrículas se convierten en elementos de Penpot. Espere pérdidas menores en las funcionalidades específicas de Figma (algunos plugins, efectos avanzados), pero la estructura general, las capas y las propiedades de estilo se conservan. Penpot importa también su formato nativo `.penpot` y los archivos SVG.

Sí. Penpot es 100 % de código abierto (MPL-2.0) y la versión autoalojada no tiene ninguna limitación en cuanto al número de usuarios, de proyectos o de archivos. No existe un plan «Team» o «Enterprise» de pago para el autoalojamiento — usted paga únicamente la infraestructura (su VPS ServOrbit). Las funciones de colaboración en tiempo real, las bibliotecas compartidas y el traspaso a desarrollo (handoff) están todas disponibles sin ningún coste de licencia.

Sí, para un uso en producción con varios usuarios. Penpot requiere HTTPS para las cookies de sesión seguras y los WebSockets que alimentan la colaboración en tiempo real. Sin un dominio HTTPS, la aplicación funciona en modo `disable-secure-session-cookies`, lo que resulta aceptable para una prueba local pero no para un equipo. Al desplegar a través del Marketplace de ServOrbit, el aprovisionador configura automáticamente el proxy inverso Nginx y el certificado Let's Encrypt a partir del dominio que usted haya indicado.

Sí. Penpot admite la autenticación OIDC (OpenID Connect) y LDAP. Puede conectarlo a Authentik (disponible en el marketplace ServOrbit) para centralizar la autenticación de toda su stack self-hosted. La configuración se realiza mediante las variables de entorno `PENPOT_FLAGS` (activar `enable-oidc`) y los parámetros del proveedor OIDC. Los usuarios se conectan entonces a través de su IdP central — SSO, MFA, passkeys — sin gestionar cuentas separadas en Penpot.

ntfy es un servidor de notificaciones push de código abierto (Apache 2.0, ~32 k ⭐): usted publica un mensaje en un topic con una simple llamada HTTP (`curl -d "Message" http://su-vps/topic`), y cualquier suscriptor — aplicación móvil, navegador, script — lo recibe en tiempo real. El autoalojamiento en ServOrbit le da topics privados ilimitados, sin límites de tasa, sin cuenta de terceros, sin suscripción mensual. Usted posee por completo su canal de notificaciones.

No. ntfy funciona por HTTP simple sin dominio: sus scripts y herramientas de monitorización pueden enviar notificaciones directamente a la dirección IP de su VPS. Un dominio añade HTTPS (recomendado para las notificaciones enviadas por la internet pública) y la compatibilidad con la Web Push API nativa de los navegadores, pero el caso de uso principal — scripts y herramientas de monitorización que envían notificaciones a la app ntfy — funciona por HTTP.

Una sola línea: `curl -d "Trabajo terminado" http://su-vps:8080/su-topic`. Añada un título con `-H "Title: Copia nocturna"` y defina la prioridad con `-H "Priority: high"`. Ningún SDK, ninguna biblioteca, ninguna API key — funciona en cualquier entorno shell que disponga de curl: cron, GitHub Actions, GitLab CI, AWX, entrypoints de Docker, scripts de Python.

Sí. Las apps oficiales de ntfy para Android (F-Droid / Play Store) e iOS (App Store) le permiten añadir cualquier servidor ntfy autoalojado como fuente de notificaciones. Introduzca la URL de su servidor (p. ej. `http://su-vps:8080`) y suscríbase a un topic. Las notificaciones llegan como push incluso cuando la app está en segundo plano — Android utiliza UnifiedPush (F-Droid) o FCM (Play), iOS utiliza APNs.

Para un VPS privado accesible únicamente a sus scripts, no hace falta ninguna autenticación. Para mayor seguridad, ejecute `docker exec <container> ntfy user add admin` para crear un usuario administrador y, a continuación, defina `NTFY_AUTH_DEFAULT_ACCESS=deny-all` en las variables de entorno para que solo los usuarios autenticados puedan publicar/suscribirse. Cada script o herramienta de monitorización obtiene su propio token de acceso mediante `ntfy token add`.

ntfy consume menos de 30 MB de RAM con la caché SQLite por defecto. El uso de disco depende de los ajustes de retención: por defecto los mensajes caducan al cabo de 12 horas y los archivos adjuntos no se almacenan en el servidor (se referencian externamente). Un VPS con 512 MB de RAM es más que suficiente para una instancia ntfy personal o de equipo que gestione miles de notificaciones al día.

restic es el motor de copia de seguridad: cifrado, deduplicado, incremental y controlado íntegramente desde la línea de comandos. Backrest es una interfaz web y un planificador situados por encima: mismo motor, mismo formato de repositorio, pero los repositorios, planes, planificaciones, retenciones, restauraciones y operaciones de mantenimiento se gestionan en el navegador en lugar de con archivos cron y scripts de shell. Sus copias de seguridad siguen siendo repositorios restic estándar, que puede abrir en cualquier momento con la herramienta restic — Backrest no introduce ningún bloqueo tecnológico.

En cualquier lugar donde restic sepa escribir, lo que incluye todos los destinos rclone: Amazon S3, Backblaze B2, Wasabi, MinIO, Azure Blob, Google Cloud Storage, SFTP/SSH, o un disco local o montado en red. Backblaze B2 es la elección habitual para un VPS — poco costoso, compatible con S3 y, sobre todo, situado fuera del dominio de fallo de su servidor, que es todo el sentido de una copia de seguridad externa.

Sí, y la tiene usted. restic cifra cada snapshot localmente, en el VPS, antes del menor envío: el destino solo recibe bloques opacos. La contraseña del repositorio es la clave de cifrado. Guárdela en un gestor de contraseñas: si la pierde, las copias de seguridad se vuelven matemáticamente irrecuperables, y ni ServOrbit ni el proveedor de almacenamiento pueden restablecer el acceso.

El contenedor en sí es ligero: menos de 100 MB de RAM en reposo y unos cientos de megabytes de imagen y de caché — un VPS de 1 GB es más que suficiente. El coste real está en el destino, y la deduplicación lo mantiene modesto: tras el primer snapshot completo, las ejecuciones siguientes solo envían los bloques modificados, de modo que un servidor de 20 GB con varios meses de retención diaria suele caber en unas pocas decenas de gigabytes.

Copia lo que se le monta. La receta ServOrbit monta `/home`, `/root` y `/etc` del host en solo lectura bajo `/host`, lo que cubre los datos de los usuarios y la configuración del sistema de un VPS clásico. Para proteger otras rutas — un directorio de datos de una aplicación, un volumen Docker — añada el montaje correspondiente en solo lectura en el archivo compose: aparecerá después en el selector de rutas del plan.

Backrest muestra el estado y el historial de cada plan en su interfaz, y ejecuta operaciones `check` programadas que verifican la integridad del repositorio en lugar de limitarse a señalar que la tarea se ha iniciado. Para una alerta activa, configure un hook en caso de fallo que apunte hacia un webhook: un topic ntfy autoalojado sirve perfectamente y envía el fallo a su teléfono esa misma noche. Así se evita el escenario clásico — descubrir una copia de seguridad rota desde hace tres meses justo en el momento en que se necesita.

Meilisearch es un motor de búsqueda full-text de código abierto (MIT, 57 k+ estrellas en GitHub) diseñado para la búsqueda de usuario: tolerancia a las erratas, resultados en menos de 50 ms, soporte nativo del árabe, del francés y del inglés. Una búsqueda SQL ILIKE recorre toda la tabla e ignora las erratas — más allá de unos pocos miles de filas, se vuelve demasiado lenta para una barra de búsqueda en tiempo real. Meilisearch preindexa sus datos y responde en unos milisegundos incluso sobre millones de documentos, sin modificar su base de datos principal.

El binario de Meilisearch en sí funciona con menos de 50 MB de RAM en reposo. El consumo real depende del tamaño de sus índices: un índice de 100 000 productos con varios atributos de texto ocupa unos 200–500 MB de RAM y otro tanto en disco (Meilisearch preconstruye sus índices invertidos para ganar rapidez). Un VPS de 1 GB de RAM basta para empezar; pase a 2–4 GB si su dataset supera el millón de documentos o si sirve un tráfico de búsqueda sostenido.

Sí. El tokenizador multilingüe de Meilisearch detecta automáticamente el idioma de cada atributo y aplica el tratamiento adecuado: segmentación por n-gramas para el árabe (que gestiona la ausencia de separadores de palabras estándar y la dirección RTL), normalización de los diacríticos y lista de palabras vacías para el francés. Un índice que mezcla campos en árabe y en francés responde correctamente a las consultas en ambos idiomas sin ninguna configuración — ideal para los proyectos bilingües de Marruecos/MENA.

El aprovisionador de ServOrbit genera automáticamente una `MEILI_MASTER_KEY` fuerte y aleatoria, e inicia Meilisearch en modo `production`. En modo producción, cada llamada a la API debe incluir o bien la master key (en la cabecera `Authorization: Bearer <KEY>`), o bien una clave de API derivada con alcance reducido — la instancia rechaza toda petición no autenticada. La master key se muestra una sola vez en su área de cliente ServOrbit después del despliegue: guárdela en un gestor de contraseñas, ya que no puede recuperarse desde el contenedor en caso de pérdida (solo es posible un reinicio con una clave nueva, lo que invalida las claves derivadas existentes).

Sí, y es la práctica recomendada. A partir de la master key, genera claves API de alcance reducido mediante el endpoint `/keys`: solo lectura sobre un índice concreto, solo búsqueda sin posibilidad de escribir ni de eliminar, acceso limitado a un subconjunto de atributos, o restricciones de filtro (el usuario solo puede buscar en sus propios datos). La clave de búsqueda puede incluirse en claro en su bundle JavaScript sin riesgo: no puede modificar ni eliminar datos. La master key, en cambio, nunca debe salir de su backend.

No. Meilisearch es un índice de búsqueda, no una base de datos transaccional. El esquema clásico: su aplicación escribe los datos en PostgreSQL (o en cualquier otra base) y luego los sincroniza con Meilisearch (mediante un webhook, un job de Sidekiq/Horizon o una tarea programada) para su indexación. Las consultas de búsqueda van a Meilisearch; las lecturas de datos completos (ficha de producto, pedido, perfil) permanecen en su base principal. Ambos son complementarios: PostgreSQL garantiza la coherencia transaccional, Meilisearch aporta la velocidad y la pertinencia de la búsqueda.

Monica CRM (AGPL-3.0, 22 k+ estrellas) es un gestor de relaciones personales, no una herramienta de ventas. Mientras que los CRM empresariales como Twenty o HubSpot hacen seguimiento de pipelines, leads y facturación, Monica sigue el lado humano: cumpleaños, notas personales, ideas de regalos, acontecimientos vitales y recordatorios de seguimiento. Está concebido para gestionar su red personal y profesional — amigos, familia, mentores, clientes — y no un embudo de ventas estructurado.

No. El registro y el inicio de sesión en Monica funcionan sin ninguna configuración de correo. El primer usuario que se registra en una instancia nueva se convierte automáticamente en administrador — no se envía ningún correo de verificación. SMTP solo resulta útil si desea que Monica le envíe recordatorios por correo electrónico o enlaces de restablecimiento de contraseña: estas funciones siguen disponibles desde el panel de control sin SMTP.

Monica v4 admite oficialmente solo MySQL y MariaDB. La receta de ServOrbit utiliza MariaDB 11, la base de datos de código abierto compatible con MySQL recomendada. PostgreSQL no es compatible con Monica v4: la aplicación se apoya en funcionalidades específicas de MySQL y su ORM apunta exclusivamente a MySQL/MariaDB.

Monica en sí consume generalmente menos de 256 MB de RAM en reposo. MariaDB añade 150–300 MB según la concurrencia de las consultas. Redis añade menos de 50 MB. En total, un VPS de 1 GB resulta cómodo para un uso personal (hasta ~5 usuarios y decenas de miles de contactos). Pase a 2 GB si prevé alojar a un equipo pequeño o realizar importaciones voluminosas con regularidad.

Sí. Monica importa los archivos vCard (.vcf), que es el formato de exportación estándar de iPhone (mediante iCloud), Android (mediante Google Contacts) y de las herramientas de escritorio (Apple Contacts, Outlook, Thunderbird). Exporte sus contactos desde su teléfono o servicio en la nube, cargue el archivo .vcf en Ajustes → Importar, y Monica asigna los campos automáticamente. También se admite la importación CSV con asignación de campos personalizada.

Monica es una Progressive Web App (PWA) — puede añadirla a la pantalla de inicio de su teléfono desde el navegador (Compartir → Añadir a pantalla de inicio en iOS; Añadir a pantalla de inicio en Chrome para Android) y se comporta como una aplicación nativa con caché sin conexión. No existe ninguna aplicación nativa oficial para iOS o Android, pero la PWA funciona bien en móvil.

SearXNG es un motor de metabúsqueda de código abierto que agrega los resultados de Google, Bing, DuckDuckGo y más de 280 fuentes en una sola consulta, sin rastrearle ni conservar su historial. Autoalojarlo en su VPS le da una URL de búsqueda privada para sus equipos y sus agentes de IA: sin coste por consulta, sin límite de velocidad y sin datos enviados a terceros.

Sí. Active el formato JSON en el archivo `settings.yml` de SearXNG (opción `formats: [html, json]`) y después apunte sus herramientas de IA a `https://su-dominio.com/search?q=<consulta>&format=json`. Open WebUI, n8n, Flowise, LangChain y CrewAI admiten todos SearXNG de forma nativa como backend de búsqueda web.

SearXNG (contenedor Python) consume menos de 256 MB de RAM y Redis añade ~30 MB. Un VPS ServOrbit con 1 GB de RAM basta para un uso personal o un equipo pequeño. Para un uso con varios agentes de IA o usuarios simultáneos, un VPS de 2 GB ofrece más holgura.

El método más sencillo es la autenticación HTTP Basic Auth configurada en Nginx — solo los usuarios con credenciales pueden acceder a la interfaz. Para un uso exclusivamente por API (agentes de IA), desactive la interfaz HTML en `settings.yml` y limite los rangos de IP autorizados en Nginx. También puede activar `limiter: true` en los ajustes para proteger una instancia pública frente a los abusos (se requiere Redis para el limitador).

SearXNG utiliza técnicas de agregación similares a las de cualquier motor de metabúsqueda. Para un uso personal o de equipo interno, el riesgo es mínimo. Para un uso público intensivo (millones de consultas al día), algunos motores pueden bloquear su IP. Active la rotación de fuentes en `settings.yml` y utilice Redis para cachear los resultados frecuentes — esto reduce considerablemente la presión sobre cada motor individual.

No. La función de etiquetado automático por IA es totalmente opcional. Karakeep funciona como un gestor de marcadores completo — guardado, crawl, capturas de pantalla e indexación de texto completo — sin ninguna clave de IA. Cuando añade `OPENAI_API_KEY` o `OLLAMA_BASE_URL`, la generación automática de etiquetas y de resúmenes se activa en los nuevos elementos guardados.

Los tres contenedores (aplicación Karakeep, Meilisearch y Chrome headless) consumen alrededor de 800 MB–1,2 GB en reposo. Un VPS ServOrbit de 2 GB de RAM es el mínimo recomendado. Si además ejecuta Ollama en el mismo VPS para el etiquetado con IA local, un VPS de 4 GB resulta más cómodo (Ollama necesita al menos 4 GB para un modelo pequeño como `phi3:mini`).

Sí. Karakeep admite la importación desde Pocket (exportación JSON), los archivos de marcadores Netscape (exportados por todos los navegadores principales, Raindrop.io y Pinboard) y su propio formato de copia de seguridad. Vaya a Settings → Import de su instancia para subir el archivo. Las importaciones grandes (miles de marcadores) se procesan en segundo plano — la importación en sí es rápida, la indexación de texto completo se realiza de forma asíncrona.

Sí. Si Ollama se ejecuta en el mismo VPS (desde el marketplace ServOrbit o instalado manualmente), añada `OLLAMA_BASE_URL=http://localhost:11434` en el entorno Karakeep de su `docker-compose.yml`. En la interfaz web, vaya a Settings → AI y seleccione su modelo Ollama preferido. Karakeep lo utilizará para el etiquetado y la síntesis sin ningún coste de API ni datos que salgan de su servidor.

Sí. Karakeep incorpora una Progressive Web App (PWA): abra la URL de su instancia en un navegador móvil, pulse «Añadir a la pantalla de inicio» y se instalará como una aplicación nativa. La integración con el menú de compartir del móvil (iOS y Android) le permite enviar cualquier enlace desde cualquier aplicación directamente a su instancia de Karakeep con un solo toque.

Gatus es una herramienta de monitorización de salud y de página de estado config-as-code (~11,7 k ⭐, Apache 2.0): usted define sus endpoints y sus condiciones de salud en un archivo YAML versionable. Uptime Kuma es un monitor de uptime con interfaz gráfica — ideal para añadir monitores sin tocar ningún archivo de configuración. Gatus ofrece condiciones más ricas (tiempo de respuesta, vencimiento TLS, regex del body, resolución DNS) y genera una página de estado pública adecuada para compartirla con sus usuarios finales.

No. Gatus funciona directamente sobre la dirección IP de su VPS — la página de estado es accesible en `http://ip-vps:8080` desde el despliegue. Se recomienda un nombre de dominio para una página de estado destinada a sus clientes (para poner Gatus detrás de nginx con HTTPS y un subdominio como `status.su-dominio.com`), pero la monitorización interna y las alertas funcionan inmediatamente sin dominio.

Conéctese por SSH a su VPS y edite `/opt/stacks/gatus/config/config.yaml`. Añada un nuevo bloque bajo `endpoints:` con la URL, el intervalo y las condiciones. Reinicie con `cd /opt/stacks/gatus && docker compose restart gatus`. El nuevo endpoint aparece en la página de estado en unos segundos. Sin navegador, sin interfaz: únicamente un archivo de texto que puede versionar en un repositorio git.

Gatus integra más de 40 canales de alerta: Slack, PagerDuty, OpsGenie, Discord, Microsoft Teams, Telegram, Pushover, ntfy, GitHub Issues, correo electrónico, webhook personalizado, Mattermost, Gotify y muchos otros. Configure el canal una sola vez en el bloque `alerting:` de su configuración y después haga referencia a él por tipo desde cada endpoint. Cada endpoint admite umbrales de activación (p. ej. `failure-threshold: 2` para alertar solo tras 2 fallos consecutivos) y umbrales de restablecimiento.

Basta con cambiar el prefijo de `url:` en su endpoint. Para TCP: `url: "tcp://db.internal:5432"` con la condición `[CONNECTED] == true`. Para DNS: `url: "dns://ns1.example.com"` con `[DNS_RCODE] == NOERROR`. Para el vencimiento TLS: conserve `url: "https://su-dominio.com"` y añada `[CERTIFICATE_EXPIRATION] > 14d` — Gatus avisará cuando queden menos de 14 días antes del vencimiento. Para ICMP: `url: "icmp://192.168.1.1"`. Todos los tipos de endpoints comparten la misma sintaxis de condiciones y los mismos canales de alerta.

Grist es una hoja de cálculo-base de datos de código abierto autoalojable (Apache-2.0, ~11 k ⭐ en GitHub). A diferencia de Google Sheets o Excel, Grist almacena los datos en tablas relacionales tipadas con referencias explícitas entre tablas, fórmulas Python ejecutadas en el servidor (acceso completo a las bibliotecas Python) y una API REST generada automáticamente en cada documento. Es la alternativa de código abierto a Airtable, sin suscripción ni vendor lock-in. Encuéntrelo en el <a href="/marketplace/developpement/grist">catálogo ServOrbit</a> o contáctenos a través de [email protected].

No. Grist almacena cada documento como un archivo SQLite en el volumen `/persist/docs/`. No se requiere ningún servicio externo: ni PostgreSQL, ni Redis, ni Celery. SQLite gestiona con comodidad miles de filas por tabla. Para instancias multiusuario muy grandes, Grist puede utilizar PostgreSQL como base de datos principal — pero el despliegue estándar en un solo contenedor utiliza SQLite para todo. Un único VPS de 1 GB de RAM basta para un uso personal o en equipos pequeños.

Cada documento Grist expone automáticamente una API REST en `http://ip-vps:8484/api/docs/<docId>/tables/<tableName>/records`. Puede listar los registros (GET), crearlos (POST), modificarlos (PATCH) o eliminarlos (DELETE) sin configurar nada. Recupere el `docId` desde la URL del documento en la interfaz web. Utilice esta API con n8n, Make, o cualquier cliente HTTP para integrar sus datos Grist en sus workflows de automatización. La autenticación por clave API está disponible en las preferencias de la cuenta.

Sí. Grist admite la colaboración en tiempo real: varios usuarios pueden editar el mismo documento simultáneamente, con propagación de los cambios en menos de un segundo y un historial de auditoría completo. El uso compartido se hace documento por documento mediante el menú Share, con tres roles: lector (view-only), editor y propietario. Para un sistema multiusuario con autenticación por correo electrónico real (no el `GRIST_DEFAULT_EMAIL` del despliegue inicial), configure un proveedor OIDC como Google Workspace, Authentik o Keycloak mediante las variables `GRIST_OIDC_*`.

Los documentos Grist son archivos SQLite en el volumen `/persist/docs/` — un archivo `.grist` por documento. Cópielos como cualquier otro archivo. Para una copia de seguridad automatizada y versionada, utilice Backrest (también en el catálogo ServOrbit): hace snapshots del volumen mediante restic y envía los incrementos cifrados hacia S3, Backblaze B2 o SFTP sin detener Grist. Grist conserva además un historial de snapshots por documento en la interfaz (menú Document → History) — práctico para restaurar una versión anterior sin acceso SSH.

Ese mantenimiento corre a su cargo. Nuestras plantillas instalan una aplicación de código abierto en su VPS y después le entregan las llaves: las nuevas versiones y los parches de seguridad dependen de usted, como todo lo que se ejecuta en un servidor no gestionado — el área de cliente ofrece la instalación y la desinstalación, no la actualización de versión. Siga el canal de publicación del editor y tome una instantánea desde su área de cliente antes de cada actualización, para poder volver atrás si sale mal. Si prefiere delegar, la prestación de administración de VPS está disponible como opción — escriba a [email protected].

Logto es una plataforma OIDC/OAuth 2.0 self-hosted que usted despliega en un VPS a través del Marketplace de ServOrbit. Una vez desplegada, cree su aplicación en la consola de administración (puerto 3002 mediante túnel SSH), obtenga el Client ID y la URL del endpoint OIDC y, a continuación, instale el SDK oficial para su framework (`@logto/react`, `logto-python`, etc.). Con 15 líneas de configuración, sus usuarios pueden registrarse, iniciar sesión con credenciales clásicas o con proveedores sociales (Google, GitHub…) y recibir un JWT firmado que su API verifica con una sola línea de middleware.

Sí. La URL ENDPOINT de Logto es el emisor OIDC: queda inscrita en cada token JWT emitido por su instancia. Este parámetro se fija en el primer arranque y no puede modificarse sin reinicializar toda la base de datos. Elija su dominio definitivo antes del despliegue. Si más adelante debe cambiar de dominio, elimine el volumen `logto_db`, vuelva a desplegar con el nuevo dominio y después reconfigure sus aplicaciones.

Son tres herramientas de autenticación con funciones distintas. Authelia es un proxy de autenticación (forward auth): añade MFA y SSO delante de sus aplicaciones existentes sin modificar su código, ideal para proteger un Grafana o un Nextcloud. Authentik es un proveedor de identidad completo (OIDC, SAML, LDAP) para centralizar el SSO de su infraestructura self-hosted. Logto es una plataforma SDK de autenticación: usted la integra en el código de su propio producto para añadirle el registro de usuarios, el inicio de sesión social, el MFA y los tokens OIDC, al estilo de Auth0 o Clerk.

La consola de administración de Logto está enlazada al puerto 3002 únicamente en localhost por razones de seguridad. Abra un túnel SSH desde su máquina local: `ssh -L 3002:127.0.0.1:3002 root@<ip-de-su-vps>`, y a continuación acceda a `http://localhost:3002/console` en su navegador. Este enfoque garantiza que el acceso a la gestión de usuarios y de aplicaciones solo sea posible desde una máquina con derechos SSH sobre el VPS.

Sí. En la consola de Logto, puede crear tantas Applications como desee (SPA, Native, Backend, Machine-to-Machine). Cada aplicación obtiene un Client ID único y sus propias URI de redirección. Así, un único VPS Logto puede centralizar la autenticación de varios proyectos: un front-end React, una API FastAPI, una aplicación móvil Flutter, cada uno con sus propios roles y políticas de acceso configurados de forma independiente.

Cal.com es el equivalente de código abierto de Calendly, autoalojado en su VPS. Las funcionalidades son muy parecidas: tipos de eventos, sincronización de calendario, videoconferencia automática, webhooks. La diferencia principal: con Cal.com sus datos de citas permanecen en su servidor, no hay límite de plan (todos los tipos de eventos son gratuitos) y puede conectar sus propias claves API de Google/Zoom. Calendly le conviene si no quiere gestionar un servidor; Cal.com, si quiere el control total.

No, no sin reinicializar la instancia. `NEXT_PUBLIC_WEBAPP_URL` queda anclado en cada enlace de reserva, en el callback OAuth y en las cookies de NextAuth desde el primer arranque. Cambiar el dominio a posteriori rompe la autenticación de todos los usuarios existentes. Elija su dominio definitivo antes de desplegar. Si le resulta imprescindible cambiarlo, elimine el volumen `calcom_db`, vuelva a desplegar con el nuevo dominio y después reconfigure las integraciones de Google Calendar y los webhooks.

El SMTP es opcional para crear la cuenta de administrador (el asistente de primer arranque no lo pide). Pero es imprescindible para enviar las confirmaciones de cita y las invitaciones de calendario a los invitados — sin SMTP, Cal.com funciona, pero los participantes no reciben ninguna notificación. Configúrelo en Ajustes → E-mail después del primer arranque. Un proveedor SMTP transaccional (Gmail App Password, Mailgun, Brevo) con 100–300 envíos al día basta para la mayoría de los usos.

En Cal.com, vaya a Configuración → Calendarios → Conectar Google Calendar. Se le redirigirá a la página de autorización de Google — acepte los permisos (lectura y escritura de calendario). Cal.com lee sus eventos existentes para bloquear las franjas ocupadas y escribe automáticamente cada nueva cita en su Google Calendar. Para que esto funcione, debe haber configurado credenciales OAuth de Google en sus variables de entorno (`GOOGLE_API_CREDENTIALS`). Como alternativa, Cal.com admite CalDAV para conectarse a Nextcloud Calendar, Fastmail o cualquier servidor CalDAV.

Cal.com (Next.js) + PostgreSQL 16 funcionan en un VPS de 2 GB de RAM para un uso individual o un equipo de menos de 10 personas, hasta 300–500 citas al día. Para un equipo más grande (> 10 usuarios, cientos de tipos de eventos) o si aloja otras aplicaciones en el mismo VPS, opte por 4 GB de RAM. El disco se consume poco: una instancia activa con 10 000 reservas solo ocupa 500 MB de base de datos.

No. Sin SMTP, puede crear igualmente una cuenta y verificar su dirección de correo electrónico: el enlace de verificación aparece en los registros de Docker. Ejecute `docker compose logs reactive-resume | grep verify` y haga clic en la URL mostrada para activar su cuenta. El SMTP sigue siendo opcional y solo se aplica a futuras funcionalidades de notificación por correo electrónico.

Sí. En la consola Docker, defina la variable de entorno `DISABLE_SIGNUPS=true` y reinicie el contenedor (`docker compose restart reactive-resume`). Los nuevos visitantes ya no podrán crear una cuenta — solo podrán conectarse las cuentas ya creadas. Para gestionar los usuarios existentes o invitar a nuevas personas, utilice la API REST o los ajustes de administración.

No, sin un procedimiento de reinicialización completo. Reactive Resume inscribe `APP_URL` en los tokens JWT y en las redirecciones OAuth en el primer arranque: cambiar la URL rompe todas las sesiones activas y todas las URL públicas de CV. Si tiene que migrar sin falta a un nuevo dominio, haga una copia de seguridad de sus datos (`docker exec db pg_dump -U postgres postgres > backup.sql`), elimine los volúmenes Docker, vuelva a desplegar con el nuevo dominio y restaure la copia de seguridad — después reconfigure `APP_URL`. Planifique su dominio definitivo antes del primer despliegue.

No, desde la versión 5.1.0. La generación de PDF se realiza íntegramente en el navegador mediante la biblioteca `@react-pdf/renderer`: el PDF se produce directamente en su navegador, sin ningún proceso Chrome, Puppeteer o Browserless en el servidor. Esto reduce la huella de memoria del servidor en unos 700 MB y elimina una dependencia de infraestructura. Si su instancia todavía funciona con una versión anterior a 5.1.0, actualice la imagen Docker (`docker pull amruthpillai/reactive-resume:latest && docker compose up -d`).

Dos volúmenes Docker contienen todos los datos de la instancia. Para una copia de seguridad completa: `docker run --rm -v reactive_resume_db:/data -v $(pwd):/backup alpine tar czf /backup/rr-db.tar.gz /data` y `docker run --rm -v reactive_resume_data:/data -v $(pwd):/backup alpine tar czf /backup/rr-data.tar.gz /data`. Para un dump SQL directo: `docker exec db pg_dump -U postgres postgres > backup.sql`. Restaure montando los archivos comprimidos en volúmenes vacíos (`docker volume create reactive_resume_db && docker run --rm -v reactive_resume_db:/data -v $(pwd):/backup alpine tar xzf /backup/rr-db.tar.gz -C /`), y después reinicie con `docker compose up -d`. Asegúrese de que `APP_URL` sea idéntica entre el origen y el destino — de lo contrario los tokens JWT no serán válidos.

Cuente con 4 GB de RAM como mínimo y 8 GB para ir holgado: ClickHouse mantiene en memoria sus índices y sus marcas, y una agregación que supere la memoria disponible se interrumpe en lugar de pasar al disco. Dos vCPU bastan para paralelizar las consultas, cuatro resultan cómodos. Lo que realmente decide es el disco: prevea de 50 a 100 GB de SSD NVMe según su periodo de retención, teniendo en cuenta que la compresión suele dividir el volumen bruto entre cinco y diez. En reposo, antes de la menor consulta, la instalación ocupa unos 270 MB de RAM.

No, y no es su función. ClickHouse es una base de datos analítica (OLAP): está hecha para recorrer y agregar tablas muy grandes, no para atender las pequeñas lecturas y escrituras transaccionales de una aplicación web. No ofrece transacciones reales, sus actualizaciones y eliminaciones son mutaciones asíncronas en lugar de operaciones inmediatas, y la lectura de una única fila es más lenta que en PostgreSQL. El esquema que funciona consiste en tener ambas en el mismo VPS: PostgreSQL o MySQL para la aplicación, ClickHouse para los registros, las métricas y los informes.

La instalación crea una cuenta `admin` con una contraseña generada para su servidor, que usted consulta en la ficha de la aplicación en su área de cliente; la cuenta `default`, que la imagen de origen entrega sin contraseña, se retira al arrancar. ClickHouse incorpora su propia consola SQL de navegador, en la ruta `/play`: si ha vinculado un dominio, responde en `https://<su-dominio>/play`; si no, abra un túnel con `ssh -L 8123:127.0.0.1:8123 root@<ip-del-vps>` y vaya después a `http://localhost:8123/play`. El servidor nunca es accesible directamente en la dirección IP pública.

Dos niveles, complementarios. A nivel de la máquina, la opción de copia de seguridad de su VPS toma una instantánea del disco entero, volúmenes Docker incluidos: es la recuperación ante desastres, y es la red que hay que activar primero. A nivel de la base de datos, ClickHouse dispone de un comando `BACKUP TABLE … TO Disk(…)` que produce una copia de seguridad coherente, exportable después fuera del servidor: es lo que hace falta para restaurar una sola tabla sin hacer retroceder todo el servidor. Evite copiar `/var/lib/clickhouse` en caliente sin detener el servicio — las fusiones de particiones en curso harían la copia incoherente.

Defina la retención en el esquema, no en un script de limpieza. Declare un TTL en el momento de crear la tabla — por ejemplo `TTL event_date + INTERVAL 90 DAY` — y particione por mes con `PARTITION BY toYYYYMM(event_date)`: ClickHouse elimina entonces en segundo plano las particiones totalmente vencidas, lo que apenas cuesta nada, en lugar de borrar las filas una a una. Inserte además por lotes de varios miles de filas en lugar de fila a fila, ya que las inserciones unitarias crean un enjambre de particiones pequeñas y desencadenan fusiones costosas. Si las consultas empiezan a ralentizarse, consulte `system.parts` y `system.merges`.

No, la imagen oficial de Node-RED no activa ninguna autenticación por defecto. El editor es accesible para cualquiera que pueda alcanzar el puerto 1880. Si asocia un dominio público, añada `adminAuth` en `/data/settings.js` antes de exponer la URL: indique un nombre de usuario y el hash bcrypt de su contraseña (obtenido con `node-red-admin hash-pw` dentro del contenedor), y después reinicie el servicio.

Sí. La plantilla Marketplace monta un volumen Docker con nombre `node-red-data` en `/data`. Node-RED guarda ahí los flujos y la configuración en cuanto usted hace clic en «Deploy». Un reinicio del VPS o del contenedor recarga automáticamente sus flujos y reanuda su ejecución. Para respaldar sus automatizaciones, cree un snapshot del VPS desde el área de cliente o exporte sus flujos en formato JSON desde el menú del editor.

En el editor, arrastre un nodo «mqtt in» o «mqtt out» desde la paleta. Haga doble clic sobre él para configurarlo: indique la dirección de su broker (IP o FQDN), el puerto (1883 por defecto, o 8883 en TLS) y el topic que escuchar o publicar. Si su broker exige autenticación, añádala en la configuración del nodo. Node-RED mantiene la conexión de forma permanente y recibe los mensajes de sus sensores en tiempo real.

Desde el editor, abra el menú principal (icono de hamburguesa) y después «Manage palette» → pestaña «Install». Busque el nodo por su nombre (p. ej. `node-red-contrib-telegrambot`, `node-red-node-mysql`). Haga clic en «Install»: Node-RED descarga el módulo npm, lo instala en `/data/node_modules` y recarga la paleta. No es necesario reiniciar el contenedor. Si la instalación falla, compruebe que el VPS tiene acceso a Internet (registro npm).

Node-RED y n8n se dirigen a perfiles distintos. Node-RED está orientado al desarrollador de bajo nivel y al IoT: gestiona el protocolo MQTT de forma nativa, permite conectar procesamientos personalizados mediante funciones JavaScript y se integra fácilmente con hardware físico. n8n está más orientado a la automatización de negocio: ofrece conectores listos para usar para cientos de servicios SaaS (Slack, Gmail, Airtable…), una interfaz más orientada al workflow no-code y una gestión de errores por ejecución. Ambos están disponibles en el Marketplace ServOrbit. La elección correcta depende de su uso: IoT/flujos en tiempo real → Node-RED; integraciones SaaS/workflow de negocio → n8n.

Sí. Cuando el puerto de transferencia (22000) no es accesible directamente, Syncthing recurre automáticamente a los servidores de retransmisión mundiales. La sincronización sigue funcionando con un ligero aumento de la latencia. Para un rendimiento óptimo, puede abrir el puerto 22000 en el firewall del VPS después del despliegue: es opcional.

Instale Syncthing en el dispositivo (equipo de escritorio, portátil, teléfono), copie su Identificador de dispositivo desde su interfaz y añádalo después como Dispositivo remoto en la interfaz Syncthing del VPS. El dispositivo verá una solicitud de emparejamiento que deberá aceptar. Tras el emparejamiento, comparta las carpetas que quiera sincronizar.

No. La interfaz web de Syncthing no tiene ninguna autenticación por defecto. La primera acción tras acceder es definir un nombre de usuario y una contraseña en Ajustes > Interfaz gráfica. La autenticación entre dispositivos utiliza automáticamente certificados criptográficos — no es necesario ningún intercambio manual de claves.

Syncthing se centra exclusivamente en la sincronización punto a punto cifrada — sin acceso web a los archivos, sin calendario, sin aplicaciones. Nextcloud ofrece una plataforma colaborativa completa con interfaz web y aplicaciones móviles. Elija Syncthing si la confidencialidad y el bajo consumo de recursos son prioritarios; elija Nextcloud para una plataforma cloud completa.

Windmill se entrega con `[email protected]` como identificador y `changeme` como contraseña. Cambie la contraseña inmediatamente después del primer inicio de sesión desde Ajustes → Usuarios. Tanto el correo electrónico como la contraseña pueden modificarse.

n8n y Activepieces están orientados a conectar servicios SaaS con flujos visuales de bajo código. Windmill se dirige a los desarrolladores que quieren escribir código real (Python, TypeScript, Go, Bash, SQL) orquestado, versionado y expuesto automáticamente como API e interfaz. Ambos enfoques son complementarios y todos están disponibles en el Marketplace.

Se recomienda un mínimo de 2 vCPU y 4 GB de RAM para hacer funcionar el servidor Windmill, un worker por defecto y un worker nativo. Añada contenedores worker adicionales si ejecuta numerosos jobs Python simultáneos o cargas de cálculo importantes.

No para un uso básico — la interfaz es accesible mediante la dirección IP o el subdominio gratuito ServOrbit facilitado en la instalación. Se recomienda un nombre de dominio si desea utilizar proveedores OAuth para la autenticación o webhooks que requieran una URL HTTPS estable.

Sí. El worker por defecto monta el socket Docker del VPS y funciona en modo privilegiado, lo que permite a los scripts ejecutar contenedores Docker efímeros para un procesamiento aislado. Esta capacidad está disponible en todos los VPS de ServOrbit y no exige ninguna configuración adicional.

Kaneo no tiene credenciales por defecto. Al abrir la URL por primera vez aparece un formulario de registro: introduzca su nombre, su dirección de correo electrónico y una contraseña. La primera cuenta creada obtiene automáticamente los permisos de administrador. Una vez configurado el equipo, cierre el registro desde Ajustes → General.

Vikunja es un gestor de tareas completo con vistas Kanban, Gantt, sincronización CalDAV y tareas recurrentes — cercano a Asana o TickTick. Kaneo es deliberadamente más sencillo: tableros Kanban, integración con GitHub y webhooks, sin las vistas adicionales. Elija Kaneo si su equipo vive en el código y en GitHub; Vikunja si necesita Gantt o sincronización con el calendario.

No. El despliegue de ServOrbit configura Kaneo con DISABLE_EMAIL_OTP_SIGN_IN=true: el inicio de sesión se hace con correo electrónico y contraseña clásicos, sin envío de correo. Un SMTP solo resulta útil si desea reactivar el inicio de sesión por enlace mágico (OTP) o enviar notificaciones.

No. Kaneo funciona sin dominio personalizado: puede acceder a él mediante la URL asignada por ServOrbit (basada en la IP de su VPS). Se recomienda un dominio para disponer de una URL memorizable y facilitar el uso compartido con su equipo, pero no es una condición para el despliegue.

Todos los datos de Kaneo están en la base de datos PostgreSQL. Para crear una copia de seguridad: `docker exec kaneo-postgres-1 pg_dump -U kaneo kaneo | gzip > kaneo-backup.sql.gz`. Para restaurar: `gunzip -c kaneo-backup.sql.gz | docker exec -i kaneo-postgres-1 psql -U kaneo kaneo`. El volumen Docker `postgres_data` contiene los archivos brutos de PostgreSQL — también puede hacer una copia de seguridad de él directamente.

Kestra es una plataforma de orquestación de workflows de código abierto basada en YAML. A diferencia de un script cron, cada flow de Kestra está versionado en Git, es observable (logs por tarea, historial de ejecución completo) y se reintenta automáticamente en caso de fallo. Usted activa sus pipelines mediante cron, webhook o llamada a la API, y visualiza el grafo de dependencias de sus tareas en una interfaz web dedicada.

n8n es adecuado para la automatización de API sin código: conectar herramientas SaaS, reaccionar a webhooks, rellenar hojas de Google. Kestra está diseñado para los pipelines de datos y ETL orientados a código: workflows YAML versionados en Git, scripts Python/SQL/Bash, runners Docker aislados y trazabilidad completa. Elija Kestra si su equipo escribe código y necesita un registro de auditoría reproducible; prefiera n8n si busca un automatizador de arrastrar y soltar para integraciones SaaS.

Kestra se ejecuta sobre la JVM y consume típicamente de 512 MB a 1 GB de RAM al arrancar, a lo que se añade PostgreSQL (unos 150 MB). Un VPS con 4 GB de RAM y 2 vCPU basta para un uso ligero o moderado (flujos programados, algunos webhooks simultáneos). Si sus flujos lanzan tareas Docker (scripts Python aislados), prevea 8 GB de RAM. Mínimo de disco: 10 GB para los datos de Kestra y los registros.

Sí. Kestra monta el socket de Docker y puede lanzar cualquier imagen Docker como tarea mediante el plugin `io.kestra.plugin.scripts.runner.docker.Docker`. Cada script (Python, Bash, Go…) se ejecuta en su propio contenedor aislado con sus dependencias, manteniendo limpio el servidor anfitrión. Kestra captura los resultados y los logs, visibles en el historial de ejecución.

ServOrbit configura Kestra con la autenticación HTTP básica activada (usuario `[email protected]` + contraseña generada automáticamente). El puerto 8080 está vinculado a 127.0.0.1 — nunca expuesto directamente a Internet. Para reforzar la seguridad: vincule un dominio y active HTTPS (nginx + Let's Encrypt gestionado por AWX); guarde su contraseña generada en un lugar seguro; y haga copias de seguridad periódicas de la base PostgreSQL, que contiene todos sus flujos y el historial de ejecución.

Garage es un almacén de objetos compatible con S3, escrito en Rust por el colectivo Deuxfleurs y publicado bajo licencia AGPLv3. Un almacenamiento de objetos le da una dirección donde depositar y recuperar archivos mediante una API estándar, en lugar de un disco montado: es lo que utilizan las herramientas de copia de seguridad (restic, Borg), las aplicaciones que conservan los archivos de sus usuarios y los sitios estáticos servidos detrás de un CDN. Como la interfaz es el S3 estándar, sus herramientas actuales funcionan sin ninguna modificación.

No, y es una decisión de diseño asumida por el proyecto. La administración pasa por la herramienta de línea de comandos `garage` y por una interfaz de administración HTTP: el servicio sigue siendo pequeño y su superficie de explotación estrecha. Existen proyectos comunitarios que ofrecen una interfaz en el navegador por encima de esa API si desea una. Sus credenciales S3, por su parte, se muestran en su área de cliente ServOrbit.

Para el caso corriente — una dirección S3 para copias de seguridad y aplicaciones — sí. Garage es más ligero, y su licencia AGPLv3 no reserva ninguna función a una edición de pago, al contrario de lo que le ocurrió a la edición comunitaria de MinIO (consola de administración retirada en 2025, y después el cese de la publicación de las imágenes Docker comunitarias). Son dos proyectos distintos y no un reemplazo carácter por carácter: valide sus integraciones específicas antes de migrar.

No, y es importante decirlo claramente. Un despliegue de un solo nodo conserva una única copia de sus objetos, en un único disco: no sustituye a una copia de seguridad. La replicación de Garage está prevista para un clúster de varias máquinas, eventualmente repartidas en varios emplazamientos — el mismo binario la admite cuando usted añade nodos. Mientras solo tenga uno, mantenga su disciplina de copias de seguridad habitual.

El servicio en sí es muy sobrio: medido en unos 3 MiB de memoria en reposo en un despliegue de un solo nodo. Lo que dimensiona su servidor es el volumen de datos que piensa almacenar, no Garage. Un VPS de gama de entrada basta para hacer funcionar el daemon; elija el disco en función de lo que vaya a depositar en él, y recuerde que un nodo único no ofrece ninguna redundancia.

Whisper reconoce 99 idiomas, entre ellos el árabe, el francés, el inglés, el español y la darija marroquí. La transcripción y la traducción al inglés las gestiona el mismo modelo, seleccionadas mediante el parámetro `task` (transcribe o translate). El modelo `base` por defecto cubre todos estos idiomas; `large-v3` mejora la precisión en los idiomas poco representados.

El modelo `base` (parámetro por defecto `ASR_MODEL=base`) funciona con holgura en 1 GB de RAM y 1 vCPU. Ofrece una precisión sólida para el habla clara en los idiomas habituales. Para las grabaciones con ruido o los acentos menos comunes, `small` es más preciso y funciona bien con 2 GB de RAM. El modelo `large-v3` ofrece la mejor precisión, pero requiere al menos 8 GB de RAM y se recomienda para los planes VPS con GPU.

Whisper se despliega como una API REST con una Swagger UI accesible en `/docs` para pruebas interactivas. No incluye una aplicación web autónoma con un formulario de subida de archivos. Para integrar Whisper en un flujo de trabajo sin programar, herramientas como n8n o Make permiten llamar a la API `/asr` directamente desde un workflow automatizado. Desde la línea de comandos, basta con `curl -F "[email protected]" https://su-direccion/asr?output=txt`.

Sí. El endpoint `/asr` es compatible con la API de transcripción de OpenAI: cualquier biblioteca o integración que llame a la API de OpenAI puede redirigirse hacia su instancia simplemente cambiando la URL base (`base_url`) y eliminando la clave API. El parámetro `output` equivale al parámetro `response_format` de OpenAI. Atención: el endpoint `/asr` no es idéntico a `/v1/audio/transcriptions` de OpenAI — algunas bibliotecas que comprueban la ruta exacta necesitan una ligera adaptación.

No. Todo el procesamiento se realiza localmente en su VPS: los archivos de audio se conservan en memoria durante la transcripción y nunca se escriben en disco ni se transmiten a OpenAI o a un servicio de terceros. Whisper es un modelo de machine learning que se ejecuta enteramente dentro de su contenedor. Ese es precisamente el interés del alojamiento autónomo para los contenidos sensibles: entrevistas, datos médicos, grabaciones internas de empresa.

ToolJet muestra un asistente de configuración en la primera apertura. Le pide su nombre completo, su dirección de correo electrónico y una contraseña. La primera cuenta creada se convierte automáticamente en el superadministrador del espacio de trabajo. No se requiere ninguna confirmación por correo electrónico — se le redirige directamente al editor tras la validación.

No. El servidor SMTP es totalmente opcional. La cuenta de administrador se crea mediante el asistente en el navegador, sin ninguna confirmación por correo electrónico. SMTP solo resulta útil si desea activar el restablecimiento de contraseña por correo electrónico o la invitación de nuevos usuarios por correo electrónico. Puede configurar SMTP más adelante en Configuración → Organización sin necesidad de volver a desplegar.

No. ToolJet CE está licenciado bajo AGPL-3.0 — sin límite de puestos, sin límite de aplicaciones, sin coste por usuario. La única restricción son los recursos de su VPS. Un VPS de 2 GB de RAM gestiona cómodamente decenas de usuarios simultáneos y decenas de aplicaciones. Para cientos de usuarios o consultas muy pesadas, se recomienda un VPS de 4–8 GB de RAM.

No. ToolJet está configurado con `requireDomain: false` en ServOrbit. TOOLJET_HOST acepta tanto `http://su-ip` como `https://su-dominio.com`. Sin dominio, el acceso público no está activado: utilice un túnel SSH — `ssh -L 8096:127.0.0.1:8096 root@su-ip-vps` — y luego abra `http://localhost:8096` en su navegador local. Asociar un dominio más adelante solo requiere actualizar `TOOLJET_HOST` en el archivo `.env` y reiniciar los contenedores.

Retool es un servicio alojado, de código cerrado, facturado por usuario y por mes (entre 10 y 25 dólares por puesto, aproximadamente). ToolJet CE es totalmente de código abierto (AGPL-3.0), autoalojado en su VPS y gratuito más allá del coste de alojamiento. Las funcionalidades son comparables — lienzo de arrastrar y soltar, conectores de fuentes de datos, acciones JavaScript, control de acceso por roles, versionado de las aplicaciones. Retool dispone de una biblioteca de conectores algo más amplia; ToolJet 3.0 (2026) añadió la construcción de aplicaciones mediante inteligencia artificial. La principal ventaja de ToolJet CE: todos sus datos de negocio permanecen en su infraestructura, sin ninguna transferencia a un tercero.

Mautic es una plataforma de automatización de marketing de código abierto: cubre las campañas de correo, la segmentación de contactos, el lead scoring, las páginas de destino y los flujos de trabajo impulsados por eventos. Listmonk es una herramienta de newsletters de alto rendimiento centrada en el envío masivo. Mautic es más adecuado si necesita escenarios de comportamiento (secuencias drip, scoring, ramificaciones condicionales); Listmonk encaja mejor si simplemente envía la misma newsletter a una lista grande.

Sí. Para enviar campañas, Mautic debe estar conectado a un relay SMTP (Amazon SES, Mailgun, Brevo, SendGrid, Postmark…). Los rangos de IP de los VPS en la nube suelen estar bloqueados por los principales proveedores de acceso a internet y de correo, lo que hace imposible el envío directo. Configure su relay en Configuración → Configuración de correo en cuanto termine el asistente de instalación, y lance un correo de prueba para confirmar la entregabilidad antes de cualquier campaña.

Mautic no impone ningún límite de software al número de contactos — el techo real es la capacidad de disco y de memoria de su VPS. En la práctica, un VPS de 4 GB de RAM gestiona cómodamente bases de 50 000 a 100 000 contactos con todas las funcionalidades activas (campañas, tracking, scoring). Para listas de varios cientos de miles, ajuste `innodb_buffer_pool_size` en MySQL (del 60 al 70 % de la RAM disponible) y considere un VPS dedicado para la base de datos.

El asistente de instalación de Mautic comprueba varios requisitos previos de PHP (extensiones mbstring, pdo_mysql, intl, gd…). Si la comprobación falla en ServOrbit, suele ser porque el contenedor aún no ha tenido tiempo de arrancar por completo. Espere 2 minutos y recargue la página. Si el problema persiste, revise los registros con `docker compose logs mautic_web` desde su VPS y compártalos con el soporte a través del área de cliente.

Sí. Mautic ofrece una integración nativa con Salesforce, SugarCRM, HubSpot, Zoho y Pipedrive mediante sus plugins de CRM. Para Twenty (que también figura en el catálogo ServOrbit), puede utilizar la API REST de Mautic y la de Twenty combinadas con una herramienta de automatización como n8n para sincronizar contactos y eventos entre ambas plataformas.

Introduzca `admin` como identificador y la contraseña generada ADMIN_PASSWORD, visible en su área de cliente ServOrbit (pestaña de credenciales de la aplicación). La autenticación está activada desde el primer arranque — la instancia nunca es accesible sin credenciales.

No. Sin dominio, acceda mediante un túnel SSH: `ssh -L 7860:127.0.0.1:7860 root@su-ip-vps` y luego abra `http://localhost:7860` en su navegador. Asociar un dominio activa el acceso HTTPS directo — ServOrbit configura automáticamente el proxy nginx y el certificado TLS.

Sí. Utilice el componente Ollama en el lienzo e indique la URL base. Si Ollama está instalado en el mismo VPS a través del Marketplace de ServOrbit, es accesible desde el contenedor de LangFlow en `http://host.docker.internal:11434`.

Ambos son constructores visuales de pipelines de LLM. LangFlow es nativo de Python y se dirige a los desarrolladores que quieren escribir componentes personalizados o exportar código Python limpio desde sus flujos. Flowise está más orientado al no-code, con un lienzo más accesible. Ambos comparten el ecosistema LangChain, pero han divergido en perfil de usuario y en herramientas.

Exporte cada flujo individualmente desde el menú del lienzo (exportación JSON). Para una copia de seguridad completa, copie la base SQLite: `docker cp langflow-langflow-1:/app/data/langflow.db ./langflow-backup.db`. Restaure volviendo a copiar el archivo al mismo destino y reiniciando el contenedor.

Linkwarden no tiene credenciales por defecto. En la primera apertura, haga clic en «Registrarse» y cree su cuenta con una dirección de correo electrónico y una contraseña — la primera cuenta se convierte automáticamente en propietaria de la instancia. No se requiere ninguna confirmación por correo electrónico. Vaya después a Ajustes → Usuarios para cerrar los registros si desea un acceso solo por invitación.

Sí. Linkwarden utiliza NextAuth.js para la gestión de las sesiones, que fija la URL pública (`NEXTAUTH_URL`) en las cookies durante el primer arranque. El dominio debe elegirse y el DNS configurarse antes de lanzar el despliegue. Modificarlo después obliga a reinicializar la base de datos y a volver a invitar a todos los miembros — es preferible resolver esta cuestión antes de empezar.

Para un equipo de 5 a 15 personas, **2 vCPU y 2 GB de RAM** con Ubuntu 24.04 ofrecen un margen cómodo. La imagen Docker de Linkwarden incorpora Playwright con Chromium para el archivado automático de las páginas — esto eleva el consumo a unos 400–600 MB en carga. En un VPS de 1 GB, puede desactivar esta funcionalidad estableciendo `DISABLE_NEXT_GENERATION_ARCHIVAL=true` desde su área de cliente, lo que hace bajar la huella por debajo de 256 MB.

Ambos gestionan marcadores, pero con enfoques distintos. **Karakeep** (antes Hoarder) está orientado al uso personal: etiquetado automático por IA, búsqueda semántica y aplicación móvil PWA. **Linkwarden** está orientado a la colaboración en equipo: colecciones compartidas, permisos granulares por miembro (lector/editor/propietario), hilos de comentarios y extensión de navegador multiusuario. Si busca centralizar la vigilancia informativa de un equipo o de una agencia, Linkwarden es la opción adecuada; para un uso individual enriquecido por la IA, Karakeep se adapta mejor.

Por defecto, cualquier persona que conozca la URL de su instancia puede registrarse. Para cerrar los registros, defina la variable de entorno `DISABLE_NEW_SIGN_UPS=true` desde su área de cliente ServOrbit. Los miembros existentes siguen accediendo a la instancia; a partir de entonces solo los propietarios podrán crear cuentas desde el panel de administración. Para los roles y permisos por colección, utilice el menú Configuración → Usuarios.

DrawDB es un editor de diagramas entidad-relación (ERD) de código abierto (AGPL-3.0, ~39 k estrellas). Permite modelar visualmente tablas de base de datos, definir relaciones FK y exportar scripts DDL SQL para MySQL, PostgreSQL, SQLite, MariaDB y SQL Server — íntegramente en el navegador, sin instalación ni cuenta requerida.

No. DrawDB conserva el estado del diagrama en el localStorage de su navegador. El contenedor Nginx no procesa ningún dato — solo distribuye archivos estáticos. Para conservar su esquema entre navegadores o equipos, exporte el archivo JSON y haga commit de él en Git.

DrawDB genera DDL SQL para MySQL, PostgreSQL, SQLite, MariaDB y Microsoft SQL Server. Seleccione el dialecto en el menú Exportar → SQL antes de copiar el script. El DDL incluye las sentencias CREATE TABLE con tipos de columna y restricciones NOT NULL, PRIMARY KEY, FOREIGN KEY y DEFAULT.

Sí. Pegue sus instrucciones CREATE TABLE en la función de importación SQL de DrawDB. Reconstruye automáticamente el diagrama ERD correspondiente, relaciones FK incluidas. Ideal para documentar una base de datos heredada o para visualizar rápidamente un esquema desconocido antes de modificarlo.

No. DrawDB funciona sin dominio: la interfaz es accesible directamente en el puerto indicado en su área de cliente de ServOrbit (3060 en el catálogo, aunque el puerto efectivo puede variar si este ya estaba ocupado). Sin dominio, no hay ningún acceso público directo: abra un túnel SSH (`ssh -L 3060:127.0.0.1:3060 root@<su-ip>`) y acceda a `http://localhost:3060`.

El acceso por defecto es [email protected] con la contraseña MyPassword. Cambie ambos inmediatamente después de su primer inicio de sesión en Administración → Su perfil.

No. Mealie funciona con una dirección IP simple. Se recomienda un dominio para el acceso desde Internet con un certificado TLS válido, pero no es necesario para un uso local o a través de VPN.

Mealie almacena recetas, imágenes y ajustes en el volumen /app/data de su VPS. Haga copias de seguridad periódicas de esta carpeta para proteger su biblioteca. También puede exportar toda la biblioteca en JSON desde la interfaz.

Sí. Mealie gestiona varios usuarios con roles distintos: administrador, usuario (puede añadir y modificar recetas) y lector (solo consulta). Cree las cuentas desde Administración → Usuarios.

Mealie analiza el marcado JSON-LD Recipe de la página de destino y extrae automáticamente el título, los ingredientes, los pasos y la foto principal. Para los sitios sin marcado estructurado, un scraper de reserva toma el relevo. Si el resultado es incompleto, el editor manual le permite completar los campos.

Seafile se centra exclusivamente en la sincronización de archivos; no incluye calendario, mensajería ni tienda de aplicaciones. Eso lo hace claramente más ligero — generalmente la mitad de RAM que Nextcloud en el mismo VPS. Elija Seafile para un rendimiento bruto de sincronización, y Nextcloud si necesita una suite de colaboración completa.

Syncthing es peer-to-peer: cada dispositivo se sincroniza directamente con los demás, sin servidor central. Seafile es cliente-servidor: todos los dispositivos pasan por el VPS central. Seafile admite varios usuarios, permisos, uso compartido por enlace y una interfaz web; Syncthing está diseñado para casos de uso de uno o dos dispositivos, sin gestión de cuentas.

Sí. Al crear una biblioteca, puede optar por el cifrado del lado del cliente. La frase de contraseña nunca sale de su dispositivo: el servidor solo almacena bloques cifrados y no puede recuperar sus archivos ni siquiera en caso de acceso no autorizado al VPS. Atención: si pierde la frase de contraseña, los archivos son definitivamente irrecuperables.

IT-Tools es una aplicación web de código abierto (MIT, ~25 k estrellas) que reúne más de 60 utilidades para desarrolladores — decodificador JWT, generadores de hash SHA-256/MD5, UUID v1/v4, codificador base64, probador de expresiones regulares, formateador JSON y muchas más. Todo el procesamiento se realiza en el navegador: no se envía ningún dato a un servidor.

No. Cada herramienta de IT-Tools ejecuta sus cálculos en JavaScript dentro de su navegador. El contenedor Nginx solo distribuye los archivos estáticos de la aplicación — nunca recibe, procesa ni transmite lo que usted introduce. Sus tokens JWT, claves de API y hashes permanecen íntegramente en su máquina.

No. IT-Tools funciona sin dominio: la interfaz es accesible directamente en el puerto indicado en su área de cliente ServOrbit (3765 en el catálogo; el puerto efectivo puede diferir si ese ya estaba ocupado). Sin dominio, abra un túnel SSH (`ssh -L 3765:127.0.0.1:3765 root@<su-ip>`) y acceda a `http://localhost:3765`.

IT-Tools no tiene autenticación integrada. Para restringir el acceso: (1) colóquelo detrás de un reverse proxy (Nginx o Caddy) con HTTP Basic Auth; (2) expóngalo únicamente en una red VPN privada; o (3) utilice el firewall de ServOrbit para abrir el puerto solo a sus rangos de IP autorizados.

IT-Tools es extremadamente ligero: la imagen Docker ocupa unos 20 MB, y el contenedor Nginx solo utiliza unos pocos megabytes de RAM en reposo. No requiere ninguna base de datos y se ejecuta cómodamente en cualquier VPS de 512 MB sin afectar a los demás servicios.

Django Stack es una plantilla de VPS preconfigurada que instala automáticamente Python 3.12, Gunicorn, Nginx y PostgreSQL 16. Está concebida para los desarrolladores Python que desean desplegar una aplicación Django en producción sin configurar manualmente los componentes del servidor.

Python 3.12 desde el PPA deadsnakes. Esta versión aporta ganancias de rendimiento del 30 al 60 % respecto a Python 3.10 en los ciclos de petición típicos de Django. Puede instalar otras versiones de Python en paralelo mediante el PPA deadsnakes y usar virtualenv para elegir la versión por proyecto.

Instale Redis con `apt install redis-server`, añada `celery` a su archivo requirements.txt y cree después una configuración de Supervisor para su worker de Celery en /etc/supervisor/conf.d/. Django Stack está diseñado para alojar Gunicorn y workers de Celery en el mismo VPS sin configuración adicional de los paquetes del sistema.

Sí. Cree un virtualenv por proyecto en /var/www/, un bloque de servidor Nginx por dominio (cada uno apuntando a un puerto Gunicorn distinto), y una configuración de Supervisor por proceso Gunicorn. Cada proyecto queda así aislado — sus dependencias, su proceso y su configuración no se perturban entre sí.

2 GB para una aplicación Django con PostgreSQL y 3 workers de Gunicorn. Prevea 4 GB si añade workers de Celery o una caché Redis cargada. Cada worker de Gunicorn consume aproximadamente entre 100 y 200 MB según el tamaño de su aplicación; ajuste el número de workers en consecuencia.

Bytebase es una plataforma DevOps de código abierto para bases de datos (licencia MIT) que aporta un flujo de revisión estructurado a las migraciones SQL. Permite enviar, validar y desplegar cambios de esquema de forma segura, con más de 200 reglas de lint automáticas, un registro de auditoría completo y una integración GitOps para PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse y más de 20 motores adicionales.

Bytebase admite más de 20 motores de bases de datos: PostgreSQL, MySQL, MariaDB, MongoDB, Redis, ClickHouse, SQL Server, Oracle, TiDB, Snowflake, Spanner, OceanBase y otros. Se conecta a sus servidores de bases de datos existentes como cliente — no sustituye su infraestructura de datos, la orquesta.

Sí. La Community Edition es gratuita, sin límite de usuarios, y cubre la totalidad del flujo de gestión de cambios, el editor SQL y el registro de auditoría. Las funcionalidades Enterprise (SSO, RBAC granular, enmascaramiento de datos, flujos de validación personalizados) requieren una suscripción de pago. En ServOrbit, usted solo paga el VPS: Bytebase en sí no cuesta nada.

Bytebase funciona cómodamente con 1 GB de RAM. El contenedor único incluye una instancia PostgreSQL integrada — no se necesita ningún servidor de base de datos externo. Para un uso en producción con muchos usuarios simultáneos o bases de datos voluminosas, se recomiendan 2 GB.

No. Se puede acceder a Bytebase sin dominio mediante un túnel SSH — `ssh -L 8080:127.0.0.1:8080 root@<ip>` y después `http://localhost:8080`. Esta configuración es adecuada para un uso de administrador individual. En cuanto varios usuarios deban acceder simultáneamente, vincule un dominio: ServOrbit configura entonces nginx y el certificado TLS automáticamente.

Sí. Gotenberg es estable, MIT, y lo utilizan en producción miles de equipos. Genera PDF aislando cada solicitud en un proceso Chromium o LibreOffice independiente — un fallo de conversión no afecta a las siguientes. Dimensione la RAM según el número de solicitudes simultáneas: cuente ~200 MB por renderizado Chromium concurrente.

Sí. Gotenberg utiliza Chromium completo: todas las fuentes web (Google Fonts mediante URL, o fuente local incrustada en base64), las variables CSS, las media queries `@print`, los flexbox y los grids se respetan. Para las fuentes locales, incorpórelas con `@font-face` y adjunte el archivo en el formulario multipart.

Gotenberg admite más de 20 formatos a través de LibreOffice: DOCX, XLSX, PPTX (y sus equivalentes OpenDocument ODT, ODS, ODP), RTF, TXT, CSV y muchos otros. La lista completa está en la documentación oficial. Envíe el archivo en multipart hacia `/forms/libreoffice/convert` — la salida siempre es un PDF.

No. Gotenberg no tiene estado (stateless): los archivos subidos y los PDF generados se almacenan en un directorio temporal y se eliminan inmediatamente después de la respuesta. Ninguna base de datos, ningún almacenamiento persistente. Sus documentos solo transitan por su propia infraestructura.

El mínimo absoluto es 512 MB, pero Chromium consume ~150–250 MB por petición concurrente. Para un uso aplicativo típico (1–3 PDF simultáneos), 1–2 GB bastan. Para cargas de trabajo intensivas (10+ PDF concurrentes o documentos LibreOffice voluminosos), opte por 4 GB o más. Gotenberg no almacena en caché los contextos de Chromium: cada petición inicia un nuevo proceso.

FastAPI es asíncrono de forma nativa, con validación mediante Pydantic y documentación OpenAPI generada automáticamente — ideal para las API REST y los microservicios. Django es un framework full-stack con administración integrada, ORM y motor de plantillas — más adecuado para las aplicaciones monolíticas. Para un backend de API puro, FastAPI es más rápido de desarrollar y de ejecutar.

Utilice Gunicorn como gestor de procesos con el worker UvicornWorker: `gunicorn main:app -k uvicorn.workers.UvicornWorker --workers 4 --bind 127.0.0.1:8000`. El número de workers recomendado es (2 × vCPU) + 1. Esto combina la gestión de procesos de Gunicorn (reinicio automático, recarga progresiva) y el rendimiento asíncrono de Uvicorn.

Sí. FastAPI no impone ninguna base de datos. Use SQLite, MySQL, MongoDB o cualquier base de datos mediante SQLAlchemy (sync o async) o Motor para MongoDB. La plantilla instala PostgreSQL 16 para los proyectos que lo necesiten — ignórelo si opta por otra base de datos.

FastAPI genera automáticamente /docs (Swagger UI) y /redoc (ReDoc) para cada endpoint definido. Acceda a https://su-dominio.com/docs después del despliegue. En producción, restrinja estos endpoints con un middleware de autenticación o un prefijo de router si su API no es pública.

1 GB de RAM basta para una API FastAPI ligera sin base de datos en el mismo VPS. Prevea 2 GB con PostgreSQL y 4 GB si añade Celery y workers Redis. Cada worker Uvicorn/Gunicorn consume aproximadamente entre 50 y 150 MB según las dependencias cargadas al arrancar.

Plane es la alternativa de código abierto (AGPL-3.0) a Jira y Linear, autoalojada en su VPS. Las funcionalidades son muy parecidas: issues con estados personalizados, ciclos (sprints) con burndown, módulos (epics), páginas wiki y vistas analíticas. La diferencia principal: con Plane, sus datos permanecen en su servidor, no hay facturación por usuario y usted controla por completo la retención. Jira y Linear son adecuados si no quiere gestionar un servidor; Plane, si quiere el control total a coste fijo.

La configuración mínima es de 2 vCPU y 4 GB de RAM con Ubuntu 24.04 para un equipo de menos de 10 personas. Para un equipo más grande o un uso intensivo, apunte a 4 vCPU y 8 GB de RAM. Plane se apoya en seis componentes (Django, React, Celery, PostgreSQL 16, Redis 7, RabbitMQ y MinIO) — todos gestionados automáticamente por la plantilla de ServOrbit. Se requiere un dominio propio para el buen funcionamiento de las redirecciones y de los certificados TLS.

Plane incluye un importador de Jira nativo: vaya a Ajustes → Importadores → Jira, introduzca la URL de su instancia Jira y un token de API de Atlassian, seleccione el proyecto a importar e inicie. Los epics se convierten en módulos, los sprints en ciclos, y las issues conservan sus descripciones, etiquetas, prioridades y estados. La importación no es destructiva: nada se modifica ni se elimina en Jira durante la migración. También está disponible una importación CSV para migrar desde Linear u otras herramientas.

Sí. Los ciclos son el equivalente en Plane de los sprints: cada ciclo tiene una fecha de inicio, una fecha de fin, un gráfico de burndown y un traspaso automático de las issues sin terminar al ciclo siguiente. La vista Gantt está disponible a nivel de proyecto y a nivel de workspace — muestra las dependencias entre issues en forma de cronología interactiva y permite arrastrar y soltar las fechas límite directamente sobre el diagrama para ajustarlas.

Sí. Instale la aplicación de GitHub de Plane (Configuración → Integraciones → GitHub) en su repositorio y, a continuación, haga referencia a las issues en sus mensajes de commit con la sintaxis `fix(#123)`, `closes #456` o `ref #789`. Plane hará transitar automáticamente la issue según la palabra clave utilizada. Las pull requests también se vinculan a las issues en la barra lateral, y las ramas creadas desde Plane llevan el nombre del identificador de la issue para facilitar la trazabilidad.

FileBrowser arranca con admin como nombre de usuario y admin como contraseña. Cambie esta contraseña desde la primera conexión en Ajustes → Usuarios para asegurar su instancia.

Sí. FileBrowser es accesible a través de la dirección IP de su VPS y del puerto asignado (8085 por defecto). Para un acceso cifrado desde Internet, asocie un nombre de dominio: la receta del Marketplace ServOrbit configura entonces el proxy inverso y el certificado HTTPS automáticamente.

Sí. FileBrowser monta dos volúmenes Docker independientes: uno para los archivos que sirve (/srv) y otro para su base de datos SQLite (/database). Ambos persisten tras los reinicios del contenedor, las actualizaciones de la imagen y los reinicios del servidor.

Sí. Desde Ajustes → Usuarios, cree tantas cuentas como necesite. Cada cuenta dispone de su propio directorio accesible (home directory) y de una cuota de almacenamiento opcional. Los permisos se gestionan por directorio: un usuario puede tener acceso únicamente a una parte del árbol de archivos.

FileBrowser ofrece autenticación por cuenta y control de acceso por directorio. Para cifrar los intercambios, colóquelo detrás del proxy HTTPS incluido en la receta del Marketplace ServOrbit (Let's Encrypt automático con su dominio). Los enlaces de compartición pública pueden ser temporales (con fecha de vencimiento) o permanentes, y están protegidos enlace por enlace — un enlace revocado deja de ser accesible.

Go (Gin) Stack es una plantilla de VPS preconfigurada que instala automáticamente Go 1.22+ desde el binario oficial de go.dev, Nginx y PostgreSQL 16. Está diseñada para los desarrolladores Go que desean desplegar una API Gin en producción sin configurar manualmente los componentes del servidor.

No. Si compila con CGO_ENABLED=0 GOOS=linux GOARCH=amd64 en su equipo, el binario resultante es 100 % estático y se ejecuta sin Go en el servidor. La plantilla instala Go 1.22+ para permitirle compilar directamente en el VPS si lo prefiere, pero no es necesario para ejecutar binarios precompilados.

Sí. La plantilla instala la cadena de herramientas de Go, Nginx y PostgreSQL — no el framework. Utilice Echo, Chi, Fiber o la biblioteca estándar net/http en su lugar. Gin se recomienda en la documentación por su adopción y por su router de cero asignaciones, pero la plantilla es agnóstica respecto al framework.

1 GB es cómodo para una API Gin sin base de datos. Añada 1 GB si PostgreSQL se ejecuta en el mismo VPS. Un proceso Gin consume normalmente entre 15 y 30 MB de RAM en reposo; el pico de memoria depende de la lógica de sus handlers y del tamaño de las cachés en memoria.

El enfoque recomendado es una unidad systemd: ExecStart apuntando a su binario, Restart=always para la recuperación automática en caso de fallo, y EnvironmentFile para los secretos. Esto aporta registro centralizado, límites de recursos y ordenación de las dependencias (p. ej.: después de PostgreSQL). Como alternativa, ejecute su binario en un contenedor Docker con --restart unless-stopped.

Next.js Stack está orientada a las aplicaciones React (Next.js), Nuxt Stack está orientada a Vue.js (Nuxt 3). El conjunto de herramientas instalado es idéntico — Node.js LTS, PM2, Nginx, PostgreSQL — pero los frameworks, su sistema de compilación y sus archivos de salida son diferentes.

Sí. Cada aplicación Next.js se ejecuta como un proceso PM2 distinto en un puerto diferente (3000, 3001, 3002…). Nginx enruta las peticiones por nombre de dominio y las redirige al proceso correcto. Un VPS de 4 GB de RAM puede alojar de 3 a 5 sitios ligeros simultáneamente.

Sí. La plantilla instala Node.js LTS y PM2, que ejecutan cualquier versión de Next.js, incluido el App Router. La opción `output: 'standalone'` en `next.config.js` funciona de forma idéntica con el App Router y con el Pages Router.

La ISR de Next.js almacena las páginas regeneradas en `.next/cache` en el disco del VPS. Esta caché persiste entre las recargas de PM2 (zero-downtime). Para no vaciarla en cada despliegue, ejecute `pm2 reload` en lugar de `pm2 restart`. Para varias instancias, utilice un handler de caché Redis.

Un VPS es preferible cuando usted tiene mucho tráfico SSR (Vercel factura por invocación), workers o crons en segundo plano, varios proyectos que mutualizar o una exigencia de coste fijo. Vercel sigue siendo la mejor opción para un prototipo rápido o un sitio ligero sin procesos anexos.

Typesense (C++, GPLv3) y Meilisearch (Rust, MIT) son dos motores de búsqueda de código abierto tolerantes a errores tipográficos con API REST, ambos disponibles en el Marketplace ServOrbit. Typesense está optimizado para requisitos de latencia estrictos e incluye la búsqueda vectorial / semántica nativa. Meilisearch es más sencillo de configurar y se prefiere para volúmenes pequeños. Ambos pueden coexistir en el mismo VPS — cada uno expone su propio puerto y su propio juego de claves de API.

No difunda nunca la clave admin en el navegador. Genere una clave de solo búsqueda (search-only) con alcance restringido mediante la API de Typesense: POST /keys con `{"actions":["documents:search"],"collections":["mi-coleccion"],"description":"clave front-end"}` utilizando la clave admin en la cabecera. La clave de solo búsqueda generada no puede modificar las colecciones ni leer otros índices. Expóngala en su bundle JavaScript; conserve la clave admin exclusivamente del lado del servidor. También puede añadir filtros integrados para restringir los resultados por tenant o categoría, que el cliente no puede eludir.

Typesense v0.25+ admite los campos de tipo `float[]` para almacenar embeddings junto a los campos de texto. Declare un campo `embedding` de tipo `float[]` en el esquema de su colección, y después envíe sus vectores (generados por OpenAI text-embedding-3-small, un modelo local Ollama, etc.) en cada documento. Para una consulta híbrida: use `vector_query` con su vector de consulta y combínelo con `q` para el ranking BM25 — Typesense fusiona las puntuaciones según un parámetro `alpha` ajustable. No hace falta ninguna base de datos vectorial separada (Qdrant, Weaviate) para este caso de uso.

Typesense carga sus índices en RAM: prevea alrededor de 1 MB por cada 1000 documentos con 3 a 5 campos de texto. Para un catálogo de 100 000 productos, cuente con ~300 MB de RAM dedicada; para un millón de documentos, ~3 GB. Un VPS de 1 GB basta para los proyectos habituales; pase a 2 o 4 GB si supera los 500 000 documentos o si activa campos de embedding (de 768 a 1536 dimensiones por documento = de 3 a 6 MB por cada 1000 documentos). ServOrbit permite el cambio de plan en línea sin reinstalación: los datos permanecen en su volumen persistente.

Typesense es compatible con el ecosistema Algolia InstantSearch: instale `typesense-instantsearch-adapter` (`npm install typesense-instantsearch-adapter instantsearch.js`) y configure el adaptador con la URL de su instancia y una clave search-only. Obtiene una barra de búsqueda con sugerencias, facetas, paginación y resaltado de los términos — sin modificar su front-end InstantSearch existente. Para React, utilice `react-instantsearch` con el mismo adaptador. Para Vue, `vue-instantsearch`. El adaptador traduce las llamadas de InstantSearch a la API de Typesense de manera transparente.

No. Mailpit es un servidor trampa: acepta todas las conexiones SMTP en el puerto 1025 y almacena cada mensaje en su base SQLite local sin transmitirlo nunca. Ningún correo electrónico llega a un buzón real, sea cual sea la dirección de destinatario configurada en su aplicación.

En las variables de entorno o en el archivo de configuración de su aplicación, defina el host SMTP en 127.0.0.1 y el puerto en 1025. Ninguna autenticación, ningún TLS requerido por defecto. En Laravel: MAIL_HOST=127.0.0.1, MAIL_PORT=1025, MAIL_ENCRYPTION=null. En Symfony: MAILER_DSN=smtp://127.0.0.1:1025. En Node.js (Nodemailer): host: '127.0.0.1', port: 1025, secure: false. Su aplicación debe ejecutarse en el mismo VPS que Mailpit para alcanzar el servidor a través del loopback.

MailHog ya no se mantiene desde 2020 y arrastra una vulnerabilidad XSS almacenada sin corregir (Exploit-DB 50971): un correo que contenga JavaScript malicioso puede comprometer la interfaz web. Mailpit es su sucesor activo, instalado por defecto en Laravel Sail (desde la v11) y DDEV (desde la v1.22). Añade la búsqueda de texto completo, la puntuación antispam con las reglas de SpamAssassin, las comprobaciones de compatibilidad HTML por cliente de correo, una API REST documentada para la CI y el soporte de POP3 — todo ello en un binario Go de menos de 50 MB de RAM.

Mailpit expone una API REST en el mismo puerto que la interfaz web (8025 por defecto). Los puntos de entrada principales: GET /api/v1/messages (lista los correos con paginación), GET /api/v1/message/{ID} (detalle de un correo), DELETE /api/v1/messages (vacía el buzón), GET /api/v1/search?query=... (búsqueda de texto completo). En PHPUnit (Laravel): utilice Http::get('http://127.0.0.1:8025/api/v1/messages') para comprobar que un correo se ha enviado realmente tras una acción. En Jest/Vitest: fetch('http://127.0.0.1:8025/api/v1/messages'). No se requiere ninguna clave de API por defecto.

Por defecto, Mailpit conserva los últimos 500 mensajes. Cuando se alcanza el límite, los mensajes más antiguos se eliminan automáticamente para dejar sitio a los nuevos. Para modificar el límite: añada la variable de entorno MP_MAX_MESSAGES a su configuración. Ponga MP_MAX_MESSAGES=0 para una retención ilimitada (cuidado con el espacio en disco), o un valor entero para definir un número preciso de mensajes. Los mensajes se almacenan en una base de datos SQLite en el volumen mailpit-data, lo que los hace persistentes entre reinicios del contenedor.

El Direct Play significa que el cliente lee el archivo original tal cual, sin conversión: uso de CPU casi nulo en el servidor. La transcodificación convierte el flujo sobre la marcha cuando el cliente no admite el formato de origen — eso consume CPU. Dé prioridad a los formatos H.264/AAC en MP4 para maximizar el Direct Play en la mayoría de los dispositivos.

Existen aplicaciones oficiales gratuitas para iOS, Android, Android TV, Roku y Amazon Fire TV. Kodi ofrece un plugin oficial de Jellyfin. La mayoría de los smart TV recientes (Samsung, LG) también están cubiertos. La interfaz web funciona en cualquier navegador sin instalación.

El espacio necesario depende de su biblioteca. Como guía aproximada: 1 GB por película SD de 90 min, de 4 a 8 GB para una película HD (1080p), de 20 a 50 GB para una película 4K. Jellyfin en sí utiliza unos 500 MB para su configuración y sus metadatos. El almacenamiento de los medios es su principal limitación.

Jellyfin es 100 % gratuito y de código abierto (GPL-2.0): ninguna funcionalidad de pago, ninguna cuenta obligatoria, ninguna telemetría. Plex es parcialmente propietario: algunas funcionalidades (sincronización sin conexión, reproductor de TV avanzado) requieren una suscripción Plex Pass. Jellyfin se instala sin cuenta; Plex impone una cuenta de servidor vinculada al servicio Plex.

Sí. Al alojar Jellyfin en un VPS ServOrbit, dispone de una IP pública dedicada y de un ancho de banda de subida superior al de una conexión residencial. Configure Nginx como proxy inverso con un certificado TLS (Let's Encrypt) y su interfaz Jellyfin será accesible desde cualquier dispositivo o navegador del mundo.

Portainer CE (Community Edition) es totalmente de código abierto bajo Apache 2.0 y cubre la gran mayoría de los casos de uso: gestión de stacks Docker Compose, control de acceso por equipo, multihost, logs en directo y terminal interactivo. Portainer BE (Business Edition) añade funciones de empresa: RBAC granular, despliegues activados por Git y registros de auditoría avanzados. En ServOrbit obtiene Portainer CE — gratuito, ilimitado, sin ninguna licencia que gestionar.

Portainer solo debe exponerse detrás de HTTPS y con una contraseña de administrador robusta. Monta el socket de Docker (`/var/run/docker.sock`), lo que equivale por definición a un acceso root en el host. En ServOrbit, el puerto 9000 solo se publica en el bucle local — nunca es directamente accesible desde Internet sin pasar por el vhost HTTPS de nginx. No exponga nunca Portainer en HTTP sin cifrar.

Portainer cubre toda la superficie Docker: contenedores aislados, imágenes, redes, volúmenes, Swarm y Kubernetes. Dockge se centra exclusivamente en las stacks Compose y se aprende más rápido para ese caso concreto — además es más ligero. Komodo apunta al GitOps multiservidor con un pipeline de despliegue completo. Si su objetivo es una vista visual completa de todo lo que Docker gestiona en un VPS — incluidos los contenedores lanzados fuera de Compose — Portainer es la herramienta más amplia.

Sí. Instale el agente Portainer en cada VPS adicional y conéctelo a su instancia principal mediante el menú Environments. Todos los hosts aparecen en una lista unificada y se controlan desde una interfaz única. Cada VPS sigue ejecutando sus contenedores localmente — no hay planificador central. Es una vista consolidada de varias máquinas, no un orquestador de clúster.

Abra un túnel SSH desde su máquina local: `ssh -L 9000:127.0.0.1:9000 root@<ip-vps>`, y navegue después hacia `http://localhost:9000` en su navegador. El túnel retransmite el puerto de forma segura sin exponer Portainer a Internet. Con un nombre de dominio, nginx hace de proxy del puerto 9000 detrás de HTTPS con un certificado emitido automáticamente y usted accede directamente a la interfaz mediante la URL elegida.

LibreChat es una interfaz de chat de código abierto y autoalojada que le permite utilizar varios proveedores de IA (OpenAI, Anthropic, Google Gemini, Ollama) desde una interfaz unificada. A diferencia de ChatGPT, LibreChat funciona en su propio VPS: sus conversaciones, sus claves de API y su historial permanecen en su MongoDB, sin transmisión a terceros.

LibreChat necesita como mínimo 2 GB de RAM y 2 vCPU (para MongoDB + Node.js). Recomendamos 4 GB de RAM para un uso corriente con varios usuarios. Si combina LibreChat con un modelo Ollama local (Llama, Mistral…), prevea 8 GB de RAM como mínimo y una CPU reciente.

Tras el despliegue, conéctese a su instancia de LibreChat y vaya a **Ajustes → Claves API**. Puede añadir una clave por proveedor (OpenAI, Anthropic, Google, etc.) directamente desde la interfaz. Como administrador, también puede configurar claves compartidas a nivel de servidor en las variables de entorno, evitando que cada usuario tenga que introducir la suya.

Sí. LibreChat admite endpoints personalizados compatibles con OpenAI. Despliegue Ollama en el mismo VPS (o en otro) y configure después un endpoint que apunte a `http://localhost:11434/v1` en `librechat.yaml`. Obtiene una configuración 100 % local con modelos como Llama 3, Mistral o Phi-3, sin que ningún dato se envíe a APIs en la nube.

LibreChat integra un sistema multiusuario. La primera cuenta creada tras el despliegue se convierte en administradora. Desde el **Panel de administración**, puede invitar usuarios, definir roles (usuario/administrador), controlar el acceso a los modelos y a los proveedores, y desactivar el registro público (`ALLOW_REGISTRATION=false`) para un uso privado. Las claves API pueden ser compartidas (administrador) o personales (por usuario).

BookStack es un wiki de código abierto self-hosted construido sobre PHP/Laravel. Organiza la documentación en **estanterías, libros, capítulos y páginas** — una jerarquía clara que hace los contenidos navegables de inmediato. Es adecuado para los equipos que documentan procedimientos, APIs o proyectos de clientes y que quieren mantener esa documentación en su propia infraestructura sin suscripción por puesto.

BookStack es poco exigente: **1 GB de RAM** y **15 GB de SSD** bastan para un equipo de menos de veinte personas. El consumo de memoria sube sobre todo con el volumen de imágenes y de archivos adjuntos subidos. Para una documentación de equipo extensa o con muchos archivos adjuntos, **2 GB de RAM y 25 GB de SSD** resultan más cómodos. La CPU se solicita poco: 1 vCPU es suficiente en la práctica totalidad de los casos.

Al final de la instalación, abra la URL de su dominio (configurado en su área de cliente). Conéctese con las **credenciales por defecto: correo electrónico `[email protected]`, contraseña `password`**. Cambie inmediatamente la contraseña en *Ajustes → Perfil* — cualquiera que conozca la URL puede utilizar esas credenciales antes del cambio. Configure después sus variables SMTP para activar las invitaciones de usuarios por correo electrónico.

Los tres son wikis de código abierto self-hosted, pero con enfoques diferentes. **BookStack** impone una jerarquía de estanterías/libros/capítulos/páginas — ideal si sus equipos necesitan una estructura rígida y navegable. **Wiki.js** es más flexible: árbol de páginas libre, numerosos motores de autenticación, almacenamiento Git opcional — adecuado para los proyectos técnicos que quieren versionar la documentación. **Docmost** es un editor colaborativo en tiempo real inspirado en Notion — adecuado para los equipos que trabajan simultáneamente en los mismos documentos. En resumen: BookStack por la estructura, Wiki.js por la flexibilidad, Docmost por la colaboración en tiempo real.

Una instancia de BookStack se restaura a partir de **tres elementos**: el dump de la base de datos MariaDB (`mysqldump`), el volumen Docker `bookstack_config` (que contiene las subidas y la configuración de Laravel), y el valor de la variable `APP_KEY`. **Sin APP_KEY**, los contenidos cifrados (en particular los secretos de sesión) no se pueden descifrar tras la restauración. Automatice un `mysqldump` diario más una copia del volumen `bookstack_config` hacia un almacenamiento externo (S3, Backblaze…) y conserve la APP_KEY fuera del servidor (en un gestor de contraseñas).

Sí — el registro Open VSX integrado cubre miles de extensiones populares: ESLint, Prettier, Python, GitLens, Tailwind CSS IntelliSense y muchas más. Cualquier extensión instalada se escribe en el volumen persistente y sigue disponible después de cada reinicio del contenedor.

Sí. Su directorio personal se almacena en un volumen Docker con nombre (`code-server-data`) montado en `/home/coder`. Todos sus archivos, extensiones, configuraciones de Git y ajustes de VS Code sobreviven a los reinicios y a las actualizaciones de la imagen. Solo se pierde el estado no guardado en memoria si el contenedor se detiene de forma inesperada.

No. Sin dominio, acceda mediante un túnel SSH: `ssh -L 8080:127.0.0.1:8080 root@<su-ip>` y luego abra `http://localhost:8080` en su navegador. Asociar un dominio añade HTTPS, lo que desbloquea el portapapeles del navegador y los Web Workers, y permite el acceso desde redes donde el puerto SSH está bloqueado.

Code Server funciona íntegramente en su propio VPS — usted controla los datos, el runtime y el coste. GitHub Codespaces es un servicio en la nube gestionado, facturado por uso (CPU + RAM por hora) y alojado en la infraestructura de Microsoft. Code Server no limita la duración de la sesión, no pone el entorno en reposo y no factura por hora — solo se aplica el coste fijo de su VPS.

Sí. La imagen `codercom/code-server` también puede ejecutarse directamente con `docker run`, o integrarse en un `docker-compose.yml` existente junto a otros servicios. En bare metal, instale Code Server directamente con el comando oficial `curl -fsSL https://code-server.dev/install.sh | sh` — el binario se instala como servicio systemd y escucha en el mismo puerto 8080.

Planka es un tablero Kanban de código abierto y autoalojado (licencia MIT), inspirado en Trello. Permite a los equipos gestionar sus proyectos con tableros, listas y tarjetas en su propia infraestructura — sin suscripción mensual ni datos alojados en un tercero.

No. Planka funciona directamente en la dirección IP de su VPS (puerto 80, mediante nginx). Si desea un acceso HTTPS con su propio dominio, vincúlelo desde su área de cliente — ServOrbit configura el certificado TLS automáticamente.

Utilice la dirección de correo electrónico `[email protected]` y la contraseña que aparece en la pestaña **Acceso** de su área de cliente ServOrbit. Después de la conexión, vaya a **Perfil → Editar el perfil** para sustituir la dirección de correo electrónico por defecto y definir una contraseña personal.

Tantos como desee. La licencia MIT no impone ningún límite de usuarios. Cree las cuentas desde el panel **Administración → Usuarios** e invítelos a los proyectos que quiera.

Planka almacena sus datos en dos lugares: la base de datos PostgreSQL (proyectos, tableros, tarjetas, miembros) y volúmenes Docker con nombre (avatares, imágenes de fondo, archivos adjuntos). Copie los dos con `docker compose exec postgres pg_dump -U appuser appdb > backup.sql` para la base de datos, y exporte los volúmenes con `docker run --rm -v <volume>:/data alpine tar czf - /data`.

Dawarich es una aplicación web de código abierto (AGPL-3.0) que sustituye a Google Timeline. Almacena su historial GPS, visualiza sus trayectos en un mapa interactivo y contabiliza los países y las ciudades visitados — todo ello alojado en su propio servidor, sin compartir sus datos de localización.

Sí. Dawarich se publica detrás de un nombre de dominio: la instalación le pide la dirección de acceso antes de arrancar, y la aplicación solo responde en el host declarado en ese momento. Utilice un subdominio de uno de sus dominios, o el subdominio gratuito que viene con su VPS — en ambos casos, ServOrbit crea el registro DNS, el reverse proxy y el certificado HTTPS. Es también lo que hace posible la sincronización con el smartphone mediante OwnTracks u Overland, que necesita una dirección accesible.

Exporte su historial mediante Google Takeout: en Cuenta de Google → Datos y privacidad → Descargar sus datos, marque «Historial de ubicaciones» y solicite el archivo. Extraiga el archivo `Records.json` e impórtelo en Dawarich mediante Configuración → Importar. El procesamiento se ejecuta en segundo plano — unos minutos para los archivos grandes.

OwnTracks (iOS y Android, gratuita, de código abierto) y Overland (iOS) son los dos clientes compatibles. Instale una de ellas, indique la URL de su servidor Dawarich en los ajustes y active el envío de la ubicación — Dawarich recibe las coordenadas en tiempo real y las traza automáticamente en el mapa.

Dawarich almacena sus datos en PostgreSQL y en volúmenes Docker con nombre. Haga una copia de seguridad de la base con `docker compose exec dawarich_db pg_dump -U app dawarich > backup.sql` y exporte los volúmenes `dawarich_storage` y `dawarich_watched` mediante `docker run --rm -v <volume>:/data alpine tar czf - /data`. Ejecute estas copias de seguridad periódicamente y guárdelas fuera del VPS.

Ruby 3.2 desde los repositorios oficiales de Ubuntu 24.04. Rails 7 y Rails 8 funcionan ambos en Ruby 3.2 sin ningún problema de compatibilidad. Si necesita otra versión, instale rbenv o asdf en paralelo y gestione varias versiones por proyecto.

Rails Stack instala PostgreSQL por defecto, la base de datos recomendada para Rails en producción. Puede instalar MariaDB o MySQL en paralelo, pero la plantilla sigue configurada para PostgreSQL: columnas JSONB, búsqueda a texto completo y compatibilidad nativa con el ORM Active Record.

Redis ya está instalado por la plantilla Rails Stack. Añada `gem 'sidekiq'` en su Gemfile, ejecute `bundle install`, cree `config/sidekiq.yml` y configure una unidad systemd que ejecute `bundle exec sidekiq -e production`. Los workers y Puma conviven en el mismo VPS — no hay ningún dyno aparte que pagar.

2 GB de RAM para una aplicación Rails sola con PostgreSQL. Añada de 1 a 2 GB adicionales si ejecuta workers de Sidekiq. Cada worker de Puma consume aproximadamente entre 200 y 400 MB en Rails; empiece con 2 workers y ajuste según el uso de memoria observado con `ps aux` o `htop`.

Sí. Configure un socket Unix Puma distinto por proyecto en `config/puma.rb`, cree un vhost Nginx por dominio y una unidad systemd por proceso Puma. Cada aplicación utiliza su propia base de datos PostgreSQL y su propio espacio de nombres Redis — no interfieren entre sí.

Firefly III es una aplicación web de código abierto (AGPL-3.0) de gestión financiera personal y profesional, autoalojada en su propio VPS. Hace el seguimiento de sus transacciones, gestiona sus presupuestos por categoría, genera informes exportables y puede importar sus extractos bancarios — sin suscripción y sin compartir sus datos con terceros.

No. Firefly III funciona sin nombre de dominio. Sin dominio asociado, accede a él mediante un túnel SSH: `ssh -L 8080:127.0.0.1:8080 root@<IP_VPS>` y luego `http://localhost:8080` en su navegador. Para un acceso permanente desde un dominio, ServOrbit configura el vhost de Nginx y el certificado HTTPS automáticamente.

Firefly III acepta archivos CSV y OFX exportados desde la mayoría de los bancos. Para los bancos europeos, también admite los conectores GoCardless (antes Nordigen) para una sincronización automática. El asistente de importación guía la correspondencia de las columnas (fecha, importe, descripción) y la deduplicación de las transacciones.

Firefly III almacena sus datos en PostgreSQL. Haga la copia de seguridad de la base con: `docker compose exec db pg_dump -U appuser appdb > backup.sql`. Programe este comando a diario mediante cron y guarde el archivo fuera del VPS (S3, SFTP) para una protección completa.

YNAB y Budgea son SaaS: alojan sus datos en sus servidores, cobran una suscripción anual (99 $/año para YNAB, 60 €/año para Budgea) y pueden cerrar su servicio. Firefly III es autoalojado: usted instala la aplicación en su VPS, sus datos le pertenecen y no hay suscripción. A cambio, usted mismo se encarga de las actualizaciones y de las copias de seguridad.

Budibase es una plataforma low-code de código abierto (GPL-3.0, más de 28 000 estrellas en GitHub) que permite construir herramientas internas, cuadros de mando y automatizaciones sin escribir código. A diferencia de Retool (SaaS propietario, facturación por puesto) o de NocoBase (que parte del modelo de datos), Budibase parte de la interfaz: usted elige una fuente de datos existente (PostgreSQL, MySQL, API REST…) y compone pantallas arrastrando y soltando. Autoalojado en su VPS, no hay ningún coste adicional por usuario y sus datos permanecen en su infraestructura.

No. Budibase funciona sin nombre de dominio mediante un túnel SSH: ejecute `ssh -L 8060:127.0.0.1:8060 root@<su-ip>` y luego abra `http://localhost:8060` en su navegador. La conexión está cifrada por SSH — no hace falta ningún certificado TLS para un acceso personal o de equipo reducido. Si desea un acceso HTTPS desde cualquier dispositivo, hay dos opciones disponibles: vincular su propio dominio desde el área de cliente de ServOrbit, o utilizar el subdominio gratuito `{app}.{dns_slug}.servorbit-dns.com` incluido con cada VPS.

En cuanto termina el aprovisionamiento, abra un túnel SSH en el puerto 8060 (véase más arriba) o vincule un dominio. La primera vez que abre Budibase aparece un **asistente de configuración** que le pide crear la cuenta de administrador: introduzca una dirección de correo electrónico y una contraseña. Esta cuenta se registra localmente en CouchDB y es válida de inmediato — no se necesita ninguna confirmación por correo electrónico. Después puede invitar a otros usuarios desde los ajustes de la organización.

Budibase integra cuatro servicios en un solo contenedor Docker: el servidor de aplicaciones Node.js, CouchDB, MinIO y Redis. El consumo de memoria en reposo es de unos **3 GB**, lo que convierte un VPS con **4 GB de RAM en el mínimo recomendado**. Para un uso en producción con varios usuarios simultáneos o conjuntos de datos voluminosos, **8 GB** ofrecen un margen de maniobra más cómodo. Si el consumo supera la memoria disponible, el contenedor puede ser eliminado por el OOM killer de Linux: elija un VPS ligeramente sobredimensionado antes que el mínimo estricto.

Todos los datos de Budibase — esquemas de aplicaciones, usuarios, automatizaciones, archivos subidos — se almacenan en el volumen Docker `budibase-data`, montado en `/data` dentro del contenedor. Para una copia de seguridad completa, archive ese volumen desde el host: `docker run --rm -v budibase-data:/data -v $(pwd):/backup alpine tar czf /backup/budibase-$(date +%Y%m%d).tar.gz /data`. El archivo obtenido contiene el volumen íntegro. Para restaurar: detenga el contenedor Budibase, extraiga el archivo en un volumen vacío, y reinicie. Programe esta copia de seguridad en cron y transfiera el archivo hacia un almacenamiento externo (S3, B2, NFS) para una protección completa.

Spring Boot Stack es una plantilla VPS preconfigurada que instala automáticamente OpenJDK 21 LTS, Maven, Nginx y PostgreSQL 16. Está pensada para los desarrolladores Java que desean desplegar una aplicación Spring Boot en producción sin configurar manualmente los componentes del servidor.

OpenJDK 21 LTS, el JDK por defecto en Ubuntu 24.04 LTS (paquete `openjdk-21-jdk`). OpenJDK 21 es una versión con soporte a largo plazo que aporta los Virtual Threads (Project Loom), la concurrencia estructurada y el pattern matching para los switch. Puede instalar otras versiones de JDK en paralelo si lo necesita.

Sí. Maven se instala con la plantilla, pero Gradle funciona sobre el mismo JDK. Instálelo con `apt install gradle` o utilice el Gradle Wrapper incluido en su proyecto (`./gradlew build`). Spring Boot Stack está diseñado para acoger cualquier proyecto Spring Boot, sea cual sea la tecnología de compilación.

Sí. Ejecute cada servicio en un puerto distinto (8080, 8081…), cree una unidad systemd por servicio y añada un bloque de servidor Nginx por servicio, enrutado por prefijo de ruta o por subdominio. Systemd gestiona cada proceso de forma independiente — no se perturban entre sí.

2 GB para una aplicación Spring Boot con PostgreSQL. La JVM consume típicamente de 300 a 500 MB en reposo para una aplicación Spring Boot estándar; prevea más si ejecuta varios servicios o si aumenta el pool de conexiones. El flag `-Xmx` permite limitar el uso del heap por servicio.

Navidrome implementa la API Subsonic, el estándar de facto del streaming musical self-hosted. En Android, se recomiendan Symfonium, DSub y Ultrasonic. En iOS, Amperfy e iSub funcionan bien. Estas aplicaciones se conectan introduciendo la URL de su instancia, su identificador y su contraseña — la biblioteca completa está disponible, con reproducción sin conexión según el cliente.

Sí. Navidrome no necesita un nombre de dominio para funcionar. Puede acceder a él desde su ordenador mediante un túnel SSH: abra un terminal y ejecute ssh -L 4533:127.0.0.1:4533 root@su-ip-vps, y después acceda a http://localhost:4533 en su navegador. Este método es seguro y no requiere abrir ningún puerto. Para un acceso móvil permanente desde cualquier lugar, configurar un subdominio con HTTPS sigue siendo la opción más práctica.

Navidrome está especializado únicamente en música: biblioteca de audio, listas de reproducción, scrobbling, API Subsonic para las aplicaciones musicales móviles. Es muy ligero (menos de 256 MB de RAM) y se configura rápidamente. Jellyfin gestiona el conjunto de los medios —películas, series, música, fotos— con una interfaz más completa, pero también más pesada. Si su uso es exclusivamente musical y desea clientes móviles dedicados (Symfonium, Amperfy), Navidrome le conviene más. Si quiere una mediateca completa con vídeo, Jellyfin está hecho para eso.

Navidrome reproduce todos los formatos de audio habituales: MP3, FLAC, AAC, OGG Vorbis, Opus, M4A, WAV, AIFF y WMA. Lee las etiquetas ID3, Vorbis Comment e iTunes directamente desde los archivos. El transcodificado al vuelo hacia MP3 u Opus es posible para los clientes que no admiten el formato original — basta con instalar ffmpeg en el servidor, algo que ServOrbit configura automáticamente.

Sí. Navidrome gestiona de forma nativa varias cuentas de usuario, cada una con sus propias listas de reproducción, favoritos, valoraciones, historial de escucha y ajustes de scrobbling. La cuenta de administrador puede crear y gestionar las demás cuentas desde la interfaz de administración. No hay ningún límite impuesto al número de usuarios — la restricción es la del ancho de banda y la capacidad del VPS.

Sí. OneDev incrusta la URL del servidor en los enlaces de clonación, en las llamadas de retorno de los webhooks de CI y en las URI de redirección OAuth. Sin un dominio correctamente configurado, esos enlaces apuntan a una dirección inaccesible. Puede usar un subdominio de su propio dominio o el subdominio gratuito de ServOrbit (`{app}.{dns_slug}.servorbit-dns.com`), que incluye HTTPS automáticamente — sin necesidad de registrar ningún nombre de dominio.

Ambas son forjas Git autoalojadas, pero OneDev va más lejos: integra un motor CI/CD con un agente de compilación incluido (sin necesidad de instalar un runner aparte), tableros Kanban y un registro de paquetes en un solo contenedor. Gitea es más ligero (~200 MB de RAM) y requiere instalar un `gitea/act_runner` aparte para el CI. Elija OneDev si quiere una plataforma DevOps todo en uno; elija Gitea si quiere una forja Git minimalista y gestiona el CI mediante un servicio externo.

Sí. OneDev incluye un agente de compilación local integrado en el contenedor `1dev/server`. En cuanto suba un archivo `.onedev-buildspec.yml` a un repositorio, se pone en cola un pipeline y se ejecuta en ese agente — sin ninguna instalación adicional. Para los equipos que necesiten compilaciones en paralelo o entornos de hardware específicos, OneDev permite añadir agentes remotos en otras máquinas, pero es totalmente opcional.

El registro de paquetes de OneDev admite los formatos Docker/OCI (imágenes), npm, Maven/Gradle, NuGet, Helm y otros. Cada formato utiliza las herramientas estándar (`docker push`, `npm publish`, `mvn deploy`) y las mismas credenciales que su instancia Git. Todo se aloja en el mismo dominio y se respalda en el mismo volumen — no hace falta ningún servicio de registro externo.

Sí. OneDev incorpora un asistente de importación que transfiere los repositorios con su historial Git, sus ramas, sus etiquetas, sus issues, sus hitos y sus pull requests desde GitHub, GitLab, Gitea y otras plataformas. El asistente está disponible en Administración del sitio → Proyectos → Importar. Tenga en cuenta que los flujos de CI deben reescribirse en formato `.onedev-buildspec.yml`, ya que OneDev no es compatible con la sintaxis de GitHub Actions.

Huginn se especializa en la vigilancia web y la agregación de datos: su Website Agent extrae contenido de cualquier página mediante selectores CSS/XPath, detecta cambios y dispara acciones según condiciones. n8n y Node-RED se centran en la automatización de flujos entre APIs con un editor visual. Huginn es la herramienta adecuada para el seguimiento de precios, alertas de cambio web y agregación RSS; n8n es más adecuado para conectar APIs de terceros sin código.

Prevea 2 GB de RAM como mínimo — aproximadamente 1 GB para PostgreSQL 16 y 1 GB para el contenedor Huginn, que incluye el servidor web y el worker en un solo proceso. Con más de 50 agentes ejecutándose en programaciones ajustadas (cada minuto), 4 GB es más cómodo. Para el disco, 15 GB son suficientes para la aplicación, la base de datos y el registro de eventos.

Tras desplegar desde el Marketplace ServOrbit, sus credenciales de administrador se generan automáticamente y están disponibles en su panel de cliente (sección Marketplace → su instancia de Huginn). Inicie sesión con el usuario admin y la contraseña mostrada. Cambie esta contraseña inmediatamente en Cuenta > Editar tras el primer acceso.

En su instancia de Huginn, haga clic en New Agent y elija el tipo deseado (Website Agent, Email Agent, Trigger Agent, etc.). Cada agente es configurable mediante una interfaz JSON con documentación integrada. En ServOrbit, SEED_EXAMPLE_AGENTS está desactivado para mantener la instancia limpia. Si desea ver ejemplos, active SEED_EXAMPLE_AGENTS: true en la configuración y reinicie el contenedor — Huginn importará escenarios de demostración.

Huginn publica nuevas imágenes en ghcr.io/huginn/huginn:latest. Para actualizar, ejecute docker compose pull && docker compose up -d en el directorio de su instancia. Huginn ejecuta las migraciones de base de datos automáticamente al arrancar. Haga siempre una copia de seguridad del volumen PostgreSQL antes de actualizar. En ServOrbit, las actualizaciones del playbook se gestionan desde su panel de cliente.

No. WhoDB funciona sin dominio mediante túnel SSH: ejecute ssh -L 8080:127.0.0.1:8080 root@<ip-vps> desde su ordenador y luego abra http://localhost:8080. Para acceso directo desde cualquier navegador sin túnel, vincule un dominio desde su área de cliente ServOrbit o use el subdominio gratuito incluido con cada VPS.

WhoDB admite PostgreSQL, MySQL, MariaDB, SQLite, MongoDB, Redis, ElasticSearch y ClickHouse. Puede configurar varias conexiones a la vez y cambiar entre ellas desde el panel izquierdo sin reiniciar la aplicación.

WhoDB no tiene cuenta de usuario propia: le solicita directamente los datos de conexión a su base de datos. En la pantalla de inicio, elija el motor en la lista desplegable (PostgreSQL, MySQL, Redis…), introduzca el host, puerto, usuario y contraseña de su base de datos y haga clic en Conectar. No se requiere ninguna cuenta de administrador de WhoDB.

En WhoDB, vaya a Configuración → Proveedor de IA e introduzca la URL de su instancia Ollama (p. ej., http://127.0.0.1:11434 si Ollama corre en el mismo VPS) o un endpoint compatible con OpenAI. Elija un modelo de la lista. Una vez configurado, aparece un campo de texto libre en la pestaña Consulta: escriba su pregunta, WhoDB genera y ejecuta la consulta SQL (o comando Redis) correspondiente.

Sí. WhoDB cifra las sesiones y las credenciales de conexión en un volumen Docker persistente (/data) en su VPS. Estos datos nunca se transmiten a un servicio de terceros. Para reforzar el cifrado, defina la variable de entorno WHODB_ENCRYPTION_KEY con una cadena aleatoria de su elección — sin ella, WhoDB genera una clave por defecto.

Elija MySQL si su aplicación lo requiere explícitamente — Magento 2, ciertas distribuciones de Drupal, o plugins PHP que verifican el nombre del motor (`mysql_get_server_info()` devuelve «MySQL», no «MariaDB»). Para la gran mayoría de aplicaciones PHP (WordPress, PrestaShop, Dolibarr), MariaDB es un reemplazo compatible con rendimiento equivalente. Ante la duda, consulte la documentación de su aplicación.

No. phpMyAdmin es accesible mediante un túnel SSH sin nombre de dominio. Abra el túnel desde su máquina: `ssh -L 8080:127.0.0.1:PUERTO root@SU-IP` (PUERTO = el número mostrado en su área de cliente), luego abra `http://localhost:8080` en su navegador. El puerto 3306 de MySQL permanece vinculado a `127.0.0.1` dentro del contenedor — accesible desde las aplicaciones alojadas en el mismo VPS.

Primero cree un usuario dedicado en phpMyAdmin: Cuentas de usuario → Agregar cuenta de usuario. Otórguele solo SELECT, INSERT, UPDATE, DELETE sobre la base de datos de su aplicación — nunca GRANT ni SUPER. Luego configure su aplicación con: host `127.0.0.1`, puerto `3306`, nombre de base de datos, usuario y contraseña. El usuario root está reservado para la administración — no lo use en su aplicación.

phpMyAdmin solo está vinculado al loopback local (`127.0.0.1`) — no es accesible directamente desde internet. Solo puede acceder a él a través de un túnel SSH, lo que significa que solo las personas con una clave SSH en el VPS pueden abrirlo. Para entornos de producción, prefiera las conexiones a través de un usuario de aplicación con permisos mínimos, y acceda a phpMyAdmin solo ocasionalmente para administración.

Sí. Ambas plantillas despliegan sus contenedores en redes Docker aisladas y no interfieren entre sí. Cada stack escucha en su propio puerto de host asignado dinámicamente por ServOrbit (solo loopback) — no es posible ninguna colisión de puertos. Un VPS de 4 GB de RAM puede alojar ambos cómodamente para cargas de trabajo moderadas.

HedgeDoc (anteriormente CodiMD) es un editor Markdown de código abierto (AGPL-3.0) para la colaboración en tiempo real. Cada nota tiene una URL única compartible; varias personas editan simultáneamente con cursores visibles. Soporta diagramas Mermaid y PlantUML, fórmulas LaTeX con MathJax, bloques de código para más de 200 lenguajes, un modo presentación y exportación a Markdown, HTML o PDF con un clic. En ServOrbit, HedgeDoc se despliega con Docker Compose y PostgreSQL como base de datos.

Sí. HedgeDoc necesita un nombre de dominio o subdominio para que los enlaces de notas compartidas y las conexiones WebSocket sean accesibles desde el exterior. Si no tienes un dominio personal, el subdominio gratuito de ServOrbit incluido con cada app funciona perfectamente: `{app}.{slug}.servorbit-dns.com`, con HTTPS incluido.

Tras el despliegue, abre tu dominio en el navegador y haz clic en Sign up. La primera cuenta registrada se convierte automáticamente en la cuenta Host (administrador). Desactiva luego el registro público en Ajustes → Sistema para evitar accesos no autorizados. La contraseña de administrador no está pregenerada — la eliges tú durante el registro.

Sí. Los diagramas Mermaid, PlantUML y Vega-lite se renderizan en la vista previa split-screen en tiempo real mientras escribes. Las fórmulas LaTeX se procesan con MathJax — usa `$...$` para fórmulas en línea y `$$...$$` para bloques. Exporta la nota completa a PDF, Markdown o HTML desde el menú principal con un clic.

HedgeDoc almacena sus datos en dos lugares: la base de datos PostgreSQL (notas, usuarios, sesiones) y el volumen Docker `hedgedoc_uploads` (imágenes subidas). Haz backup de ambos con: `docker compose exec -T database pg_dump -U appuser appdb | gzip > backup.sql.gz` `docker run --rm -v hedgedoc_uploads:/data alpine tar czf - /data > uploads.tar.gz` Automatiza estos comandos con un cron job diario.

Trigger.dev es una plataforma open source (Apache-2.0) de orquestación de tareas en segundo plano para TypeScript. Permite definir tareas duraderas directamente en el código — se ejecutan con reintentos automáticos, control de concurrencia y un panel en tiempo real. A diferencia de BullMQ o un cron simple, las tareas de Trigger.dev guardan su estado entre pasos, por lo que un fallo nunca hace empezar desde cero. En ServOrbit el stack completo (webapp, PostgreSQL, Redis, ElectricSQL, docker-provider, coordinator) se despliega con un solo compose.

Sí. El sistema de inicio de sesión con magic link genera URLs de callback a partir de las variables de entorno `LOGIN_ORIGIN` y `APP_ORIGIN`. Sin un dominio válido estos enlaces son incorrectos y la autenticación falla. En ServOrbit el subdominio gratuito `{app}.{slug}.servorbit-dns.com` incluido con cada VPS funciona perfectamente — disponible inmediatamente después del despliegue con HTTPS integrado.

Trigger.dev usa autenticación magic-link — sin contraseña. Abre `https://tu-dominio` e introduce tu dirección de correo. El enlace de autenticación se imprime en los logs del contenedor webapp — recupéralo con: `docker compose logs webapp | grep 'magic-link'`. Pega el enlace en tu navegador para acceder al panel. No se necesita servidor de correo para este primer acceso.

Trigger.dev usa ElectricSQL para sincronizar el estado de las ejecuciones en tiempo real entre la base de datos y la interfaz webapp. ElectricSQL requiere slots de replicación lógica de PostgreSQL, que solo están disponibles cuando `wal_level` está en `logical`. El compose de ServOrbit incluye esta configuración en el comando de inicio de PostgreSQL — no hay que hacer ningún cambio manual.

Descarga las últimas imágenes y reinicia el stack: `docker compose pull && docker compose up -d`. Trigger.dev ejecuta las migraciones de base de datos automáticamente al arrancar la webapp. Consulta las notas de versión en github.com/triggerdotdev/trigger.dev/releases antes de cada actualización — algunas versiones mayores pueden requerir pasos de migración adicionales.

Automatisch es una alternativa open-source a Zapier, auto-hospedada en tu VPS. Te permite conectar más de 100 apps (GitHub, Slack, Notion, Stripe, Google Sheets…) usando desencadenadores y acciones visuales, sin escribir código. A diferencia de las soluciones en la nube, todos tus datos permanecen en tu servidor sin suscripciones ni límites de tareas.

Automatisch genera URLs únicas de webhook desde la variable `HOST`. Estas URLs permiten que servicios externos (GitHub, Stripe, Typeform…) envíen eventos a tus workflows. Sin un dominio válido, las URLs apuntan a `localhost` y no son accesibles desde Internet. En ServOrbit, el subdominio gratuito incluido con cada VPS funciona desde el despliegue.

Después del despliegue, ve a `https://tu-dominio/auth/sign-up`. Introduce tu dirección de email y una contraseña para crear la primera cuenta de administrador. No se envía email de confirmación: quedas conectado inmediatamente. Se recomienda crear la cuenta justo después del despliegue, antes de que alguien más acceda a la URL.

Para integraciones OAuth (Slack, GitHub, Google Sheets, Notion…), crea una app OAuth con el proveedor y registra sus credenciales en Automatisch. Introduce el `CLIENT_ID` y `CLIENT_SECRET` en Settings → Apps. La URL de callback suele ser `https://tu-dominio/app/<service>/auth/callback`. Una vez configuradas, la conexión OAuth funciona mediante el botón **Connect** desde la pestaña Connections.

Descarga las últimas imágenes Docker y reinicia el stack: `docker compose pull && docker compose up -d`. Automatisch ejecuta automáticamente las migraciones de base de datos al arrancar. Consulta las notas de versión en github.com/automatisch/automatisch/releases antes de cada actualización — algunas versiones mayores pueden requerir pasos de migración específicos.

Kimai es una aplicación de seguimiento de tiempo open source (MIT) que alojas en tu propio VPS. Permite registrar horas por proyecto, cliente y actividad, definir tarifas horarias, generar partes de horas y facturas PDF, y producir informes detallados — sin suscripción mensual y sin compartir datos con terceros.

No. Kimai funciona sin dominio vía túnel SSH: `ssh -L 8080:127.0.0.1:8001 root@<ip-vps>` y luego `http://localhost:8080`. Para acceso desde cualquier navegador, añade un dominio desde el panel de ServOrbit o usa el subdominio gratuito incluido con cada VPS.

Tus credenciales de administrador aparecen en la tarjeta de la app del área de cliente justo después del despliegue: usuario `[email protected]`, contraseña generada automáticamente. Una vez dentro, puedes cambiar el correo y la contraseña desde los ajustes de perfil.

Sí. Kimai incluye un módulo de facturación integrado. Filtra tus registros de partes de horas por cliente y periodo, luego haz clic en **Crear factura** para obtener un documento PDF o HTML. Puedes personalizar la plantilla (logo, colores, condiciones de pago, IVA) desde los ajustes de facturación.

Todos los datos de Kimai se almacenan en tres volúmenes Docker: kimai_db (base de datos MySQL), kimai_data (archivos subidos) y kimai_public (avatares). Realiza copias con rsync o SFTP desde el host, o usa mysqldump para exportar la base de datos en SQL. Kimai también exporta partes de horas en CSV y XLSX directamente desde la interfaz.

CapRover es una plataforma PaaS (Plataforma como Servicio) de código abierto que te permite desplegar aplicaciones en pocos clics sobre tu propio servidor. Basado en Docker y Docker Swarm, gestiona los certificados SSL automáticamente mediante Let's Encrypt y ofrece más de 280 plantillas preconfiguradas (WordPress, Ghost, n8n, Nextcloud…). En ServOrbit, CapRover está disponible en el Marketplace y se aprovisiona en menos de 60 segundos.

No, no se necesita un dominio para empezar con CapRover. El panel de administración es accesible en el puerto 3000 de tu VPS inmediatamente después del aprovisionamiento. Sin embargo, se necesita un dominio comodín (p. ej. ``*.apps.midominio.com``) si quieres exponer tus apps desplegadas bajo subdominios dedicados — esta configuración se hace desde el propio panel de CapRover, después de la instalación.

Después de aprovisionar el VPS desde el Marketplace de ServOrbit, accede a `http://<IP-de-tu-VPS>:3000` en tu navegador. La página de inicio de sesión aparece de inmediato. La contraseña predeterminada es `captain42` — cámbiala en el primer inicio de sesión en Ajustes → Captain Settings. Luego puedes configurar tu dominio comodín para acceder al panel vía `captain.midominio.com`.

CapRover en sí consume alrededor de 200 a 300 MB de RAM. El mínimo para un uso real (CapRover + algunas apps desplegadas) es de 2 GB de RAM; ServOrbit recomienda el plan VPS Power (8 GB) para una experiencia óptima. Ten en cuenta que cada aplicación que despliegues a través de CapRover consume su propia memoria — elige un plan según tu carga de trabajo.

Sí, CapRover soporta múltiples métodos de despliegue: desde un repositorio Git (GitHub, GitLab, Bitbucket) con webhook para despliegues automáticos, desde un `Dockerfile` o archivo `captain-definition`, o mediante las más de 280 plantillas de la comunidad en un clic. También ofrece una CLI (`caprover deploy`) para pipelines CI/CD.

No, Homepage no tiene autenticación integrada. Está diseñado para acceso loopback (mediante túnel SSH) o VPN. Para exponer Homepage en una URL pública, póngalo detrás de un proxy inverso que añada HTTP Basic Auth u OAuth, o use Cloudflare Access delante de la instancia.

Desde la versión 0.9.0, Homepage valida la cabecera HTTP Host para prevenir ataques de Host Header Injection. Sin esta variable obtendrá un error 'Invalid host'. En un VPS de ServOrbit, si accede mediante túnel SSH (http://localhost:3000), use HOMEPAGE_ALLOWED_HOSTS="*". Si tiene un dominio (p. ej. home.midominio.com), póngalo ahí para mayor seguridad.

Homepage lee los metadatos de Docker a través del socket montado en solo lectura (/var/run/docker.sock:ro). Añada las siguientes etiquetas a cada contenedor que quiera que aparezca: homepage.group (el grupo, p. ej. 'Medios'), homepage.name (el nombre que se muestra), homepage.href (la URL). Homepage los detecta y los muestra automáticamente sin editar services.yaml.

Toda la configuración de Homepage vive en archivos YAML montados en un volumen Docker con nombre (homepage-config), accesible en /opt/stacks/homepage/config/ en su VPS. Los archivos principales son: services.yaml (sus servicios agrupados), bookmarks.yaml (sus enlaces favoritos), widgets.yaml (la barra de widgets superior), settings.yaml (tema, idioma, motor de búsqueda). Los cambios se aplican automáticamente en la siguiente recarga de página — no es necesario reiniciar el contenedor.

Homepage usa menos de 128 MB de RAM para el contenedor — no requiere base de datos. Es una de las aplicaciones más ligeras del Marketplace. En un VPS de ServOrbit, incluso el plan de entrada es más que suficiente para Homepage. Planifique el margen para los demás servicios que quiera mostrar en el panel (Nextcloud, Jellyfin, etc.) más que para Homepage en sí.

Directus es un headless CMS y data platform de código abierto (Apache-2.0) que se posa sobre cualquier base SQL — PostgreSQL, MySQL, SQLite, MariaDB — y autogenera una API REST y GraphQL completa encima. También ofrece una interfaz de administración no-code para modelar contenido, gestionar registros y establecer permisos granulares. En producción actúa como la trastienda de aplicaciones web y móviles — un frontend consulta `/items/<collection>` vía REST o GraphQL y Directus devuelve los datos sin que un desarrollador haya escrito un solo endpoint.

No. Directus funciona sin dominio mediante un túnel SSH: `ssh -L 8055:127.0.0.1:<port> root@<vps-ip>` y luego `http://localhost:8055`. Para front-ends en producción que necesiten llegar a la API desde el exterior, vincule un dominio desde su área de cliente ServOrbit — nginx hace de proxy al contenedor Directus por HTTPS automáticamente. También puede usar el subdominio gratuito `{app}.{dns_slug}.servorbit-dns.com` incluido con cada VPS.

El despliegue de ServOrbit usa SQLite por defecto — una base de datos de un solo archivo, sin servicio externo que gestionar. Es el punto de partida recomendado para uso individual o pruebas de la API. Para cargas de trabajo multiusuario o altas tasas de lectura/escritura, edite el archivo Compose en `/opt/directus/` y cambie a PostgreSQL añadiendo un contenedor `postgres:16` y reemplazando `DB_CLIENT=sqlite3` por `DB_CLIENT=pg`.

Directus con SQLite (la configuración predeterminada en ServOrbit) funciona cómodamente con 512 MB de RAM. Para un proyecto en producción con varios usuarios simultáneos o transformaciones de imágenes frecuentes, se recomienda 1 GB. Si añade PostgreSQL en el mismo VPS, prevea 2 GB en total. Un VPS ServOrbit Cloud S (1 GB de RAM) es suficiente para empezar; pase al Cloud M (2 GB) para uso en equipo.

Ambos se apoyan sobre una base SQL existente y generan una API, pero su enfoque difiere. NocoDB está orientado a la entrada y organización de datos: su interfaz se parece a una hoja de cálculo tipo Airtable, ideal para que equipos no técnicos creen y editen registros sin código. Directus está más orientado al desarrollador: genera una API consumible por aplicaciones front-end y hace hincapié en el control del esquema, los flujos de automatización y la gestión de medios. En la práctica, NocoDB es adecuado para una herramienta interna o un CRM ligero, mientras que Directus es mejor como backend de una aplicación web o móvil pública.

No. En modo standalone, Lobe Chat funciona sin dominio mediante un túnel SSH: `ssh -L 3210:127.0.0.1:3210 root@tu-vps` y `http://localhost:3210`. Para una URL HTTPS pública permanente, vincule un dominio desde su panel de ServOrbit o use el subdominio gratuito del VPS — nginx redirige Lobe Chat por HTTPS sin configuración manual.

En modo standalone (imagen Docker sin base de datos), las claves API se guardan en el navegador (localStorage) y no salen de su dispositivo. Para centralizarlas en el servidor y ocultarlas a los navegadores, cambie al modo base de datos con PostgreSQL — documentado en nuestra guía de despliegue avanzado en el blog.

Añada la variable de entorno `ACCESS_CODE=tu-secreto` al arrancar el contenedor: Lobe Chat pedirá este código en cada sesión nueva. Para mayor seguridad, coloque un reverse proxy con autenticación básica delante del puerto 3210 (Nginx `auth_basic`, Caddy `basicauth`) o restrinja el acceso a ciertas IPs mediante el cortafuegos.

Sí. Si Ollama está en el mismo VPS, establezca `http://localhost:11434` como URL de Ollama en Ajustes → Proveedores → Ollama. Dentro del contenedor Docker, use `http://host.docker.internal:11434` si Docker no tiene acceso a la red del host. Obtendrá un asistente local al 100% (Llama 3, Qwen, Mistral…) sin coste de API — aumente la RAM del VPS según el tamaño del modelo.

En modo standalone (imagen Docker por defecto), el historial de chat se guarda en el navegador (localStorage): no se conserva si cambia de navegador o dispositivo, y reiniciar el contenedor no lo borra. Para persistencia en el servidor, utilice el modo base de datos (PostgreSQL + volumen Docker) documentado en nuestra guía avanzada — todas las conversaciones quedan guardadas y son accesibles desde cualquier dispositivo.

No. El `MASTERKEY` (variable `ENCRYPTION_KEY` en ServOrbit) se utiliza para cifrar los secretos en la base de datos PostgreSQL desde el primer arranque. Cambiarlo posteriormente haría ilegibles todos los secretos y ZITADEL se negaría a iniciar. Guárdelo en un gestor de contraseñas seguro.

No. ZITADEL fija el `issuer` OIDC (la URL de su instancia) en el primer arranque a través de `ZITADEL_EXTERNALDOMAIN`. Cambiarlo rompe todas las integraciones OIDC existentes. Si necesita otro dominio, reinstale la instancia desde cero.

Sí. ZITADEL está escrito en Go y consume menos de 100 MB de RAM en reposo, frente a 512 MB a 1 GB de Keycloak en JVM. Por tanto, es adecuado para VPS de gama entrada (2 GB RAM). Un VPS de 2 GB RAM es suficiente para uso en equipo (10–50 usuarios).

En la consola de ZITADEL, vaya a **Instance Settings** → **Login Policy** → active **Passkeys / WebAuthn**. Los usuarios pueden entonces registrar su dispositivo (Touch ID, Face ID, clave FIDO2) desde **My Profile** → **Passwordless**.

ZITADEL está diseñado de forma nativa para multi-tenancy. Cada **Organización** es un espacio aislado con sus propios usuarios, grupos, aplicaciones y políticas de seguridad. Los usuarios pueden pertenecer a varias organizaciones con distintos roles en cada una. Los tokens JWT incluyen automáticamente los claims de organización.

No. SiYuan funciona en el puerto 6806 sin nombre de dominio. Abre un túnel SSH desde tu máquina local: `ssh -L 6806:127.0.0.1:<port> root@<ip-vps>` luego accede a `http://localhost:6806`. Para acceso HTTPS permanente, adjunta un dominio desde tu panel ServOrbit o usa el subdominio gratuito `{app}.{dns_slug}.servorbit-dns.com`.

ServOrbit genera automáticamente un código de acceso (`ADMIN_PASSWORD`) al aprovisionar el VPS. Este código se pasa a SiYuan mediante la variable de entorno `SIYUAN_ACCESS_AUTH_CODE` y protege el acceso a la interfaz web. Puedes encontrarlo en tu bóveda de credenciales de ServOrbit.

Sí. SiYuan ofrece apps nativas de código abierto para Windows, macOS, Linux, iOS y Android. En la configuración de la app, establece el endpoint de sincronización en la dirección HTTPS de tu VPS e introduce tu código de acceso. La sincronización es incremental y cifrada de extremo a extremo.

SiYuan permite exportar documentos individuales o cuadernos completos en varios formatos. Desde el menú contextual de un documento o cuaderno, elige Exportar y selecciona: Markdown, HTML, Word (.docx) o PDF. También puedes copiar el volumen Docker `/siyuan/workspace` para una copia de seguridad completa.

SiYuan normalmente consume menos de 256 MB de RAM para un espacio de trabajo personal activo. Un VPS de 1 GB es suficiente para uso individual o un equipo de dos a tres personas. Para espacios de trabajo con muchos enlaces o uso intensivo multiusuario, 2 GB de RAM ofrecen mejor fluidez.