Cómo autoalojar Gitea en un VPS

Puedes autoalojar Gitea en un VPS de VoyraCloud seleccionando la imagen de aplicación preinstalada, creando el primer administrador a través de SSH y luego utilizando la interfaz web, Git HTTPS o Git SSH para tus repositorios. La imagen elimina el paso de instalación manual, mientras que la política de cuentas, dominios, HTTPS, acceso a repositorios, actualizaciones, copias de seguridad y respuesta a incidentes permanecen bajo tu control.

TL;DR

La imagen de aplicación Gitea de VoyraCloud proporciona una instancia de Gitea Community Edition preinstalada en Cloud VPS y Residential IP VPS.
La página de instalación está bloqueada antes de la entrega. Crea el primer administrador a través del comando SSH que se muestra en los detalles de tu recurso, no a través de un asistente de instalación expuesto públicamente.
El puerto 3000 está vinculado a la interfaz de bucle invertido del VPS. Usa el comando SSH Tunnel en los detalles del recurso para el primer inicio de sesión web; no está expuesto como HTTP público.
Agrega un dominio, proxy inverso y HTTPS de confianza antes de publicar la interfaz web o usar Git HTTPS. Gitea SSH Git utiliza el puerto público separado 2222 después de que agregues una clave pública a tu cuenta.
El registro de nuevos usuarios está deshabilitado por defecto. El administrador decide si crear usuarios manualmente o cambiar la política de registro.
Los repositorios, cuentas, problemas, solicitudes de extracción, paquetes, adjuntos, configuración y secretos persisten a través de un reinicio normal del VPS, pero la persistencia del reinicio no es una copia de seguridad fuera del servidor.
VoyraCloud no actualiza, respalda, monitorea ni administra automáticamente la instancia de Gitea después de la entrega.

¿Qué es Gitea?

Gitea es un servicio de desarrollo de software de código abierto para alojar repositorios Git y colaborar en código fuente. Proporciona una interfaz web en torno a flujos de trabajo estándar de Git junto con cuentas de usuario, organizaciones, permisos de repositorio, solicitudes de extracción, problemas, proyectos, wikis, lanzamientos, paquetes, webhooks y acceso a API.

La documentación oficial de Gitea describe la instalación y administración para equipos que desean operar su propio servicio. El autoalojamiento es útil cuando deseas que el servicio de repositorio, la ubicación de almacenamiento, la política de cuentas, el acceso a la red, el momento de las actualizaciones y el proceso de copia de seguridad estén bajo tu propia administración.

Un VPS de Gitea es una opción práctica para:

Un desarrollador que desea repositorios privados en un servidor personal.
Un pequeño equipo que necesita alojamiento Git, revisión de código, problemas y permisos de organización.
Una agencia que mantiene repositorios separados para proyectos de clientes.
Un equipo de infraestructura que conecta repositorios a sistemas de implementación a través de claves SSH, tokens de acceso, webhooks o APIs.
Un laboratorio o entorno interno que necesita una alternativa ligera a una plataforma de desarrollo de software más grande.

El autoalojamiento no hace que las operaciones de repositorio sean libres de mantenimiento. Alguien sigue siendo responsable de la seguridad del sistema operativo, las actualizaciones de Gitea, la política de autenticación, HTTPS, las copias de seguridad, el crecimiento del almacenamiento, la prevención de abusos y las pruebas de recuperación.

¿Cómo comienzas con la imagen de Gitea de VoyraCloud?

El camino de implementación más rápido es crear un VPS de VoyraCloud compatible con la imagen de Gitea y ejecutar el comando de configuración del administrador privado desde los detalles del recurso. No necesitas instalar Docker, Gitea o la base de datos inicial manualmente.

Abre la página de VoyraCloud para Gitea desde el enlace anterior y continúa con el flujo de compra del VPS.
Selecciona una configuración de Cloud VPS o Residential IP VPS elegible. Cloud VPS es la opción de propósito general para alojamiento Git; Residential IP VPS sigue estando disponible cuando tu carga de trabajo más amplia necesita específicamente las características de red de ese producto.
Elige cualquier región actualmente ofrecida por el producto VPS seleccionado y confirma que Gitea está seleccionado en la sección de Imágenes.
Crea el VPS y espera hasta que el recurso y la aplicación estén listos.
Abre los detalles del recurso y localiza la sección de Aplicación.
Copia el comando de configuración del administrador. Sigue este patrón:

ssh -t -p <ssh-port> <ssh-user>@<server-ip> 'sudo /usr/local/sbin/voyra-gitea-create-admin'

7. Ejecuta el comando desde tu terminal e ingresa el nombre de usuario y el correo electrónico del administrador. La CLI oficial de Gitea genera una contraseña aleatoria de un solo uso de 24 caracteres y la muestra solo en la sesión SSH actual.

8. Copia el comando SSH Tunnel de la sección de Aplicación y mantén esa sesión de terminal abierta. Sigue este patrón:

ssh -N -L 3000:127.0.0.1:3000 -p <ssh-port> <ssh-user>@<server-ip>

9. Abre la URL de acceso local en tu navegador:

http://127.0.0.1:3000

10. Inicia sesión con la cuenta de administrador y la contraseña de un solo uso, luego establece una nueva contraseña cuando Gitea requiera el cambio.

11. Crea un repositorio de prueba privado, agrega una clave pública SSH y verifica una clonación y un push SSH.

12. Conecta tu dominio, configura HTTPS de confianza, actualiza la configuración de la URL pública de Gitea y confirma que los enlaces de clonación generados utilizan la dirección prevista.

13. Reinicia el VPS una vez y verifica que Gitea regrese automáticamente con el administrador, el repositorio de prueba, el historial de commits, las claves y la configuración intactos.

14. Crea una copia de seguridad fuera del servidor y realiza una prueba de restauración antes de confiar en la instancia para código fuente importante.

El comando de configuración está intencionadamente separado de la página web. El asistente de instalación público ya está bloqueado, por lo que un visitante de internet no puede reclamar una nueva instancia creando el primer administrador antes que el propietario. El comando también se detiene si ya existe un administrador.

Usa el nombre de usuario SSH y el puerto que se muestran para tu recurso VPS. No asumas que cada servidor usa root o el puerto 22. La conexión SSH del VPS utilizada para la administración también es diferente del punto final SSH Git de Gitea en el puerto 2222.

¿Qué incluye la imagen de la aplicación?

La imagen de la aplicación Gitea incluye un punto de partida persistente de un solo servidor, no un servicio de alojamiento de código fuente administrado. El límite de entrega determina lo que debes configurar antes del uso normal del equipo.

Entregado por la imagen de la aplicación	Gestionado por el usuario o no incluido
Lanzamiento estable de Gitea Community Edition aprobado para la imagen	Actualizaciones automáticas de Gitea
Entorno VPS basado en Ubuntu	Administración del sistema operativo gestionada
Gitea ejecutándose en el contenedor oficial con una base de datos SQLite local	Servicio PostgreSQL o MySQL externo
Página de instalación bloqueada	Asistente de instalación web pública
Comando SSH privado para crear el primer administrador	Administrador precreado o contraseña fija
Registro deshabilitado por defecto	Provisionamiento automático de miembros del equipo
Backend web en el puerto de bucle invertido `3000`	Exposición HTTP pública, registro de dominios, proxy inverso y HTTPS automático
SSH Git en el puerto `2222`	Claves SSH de usuario preinstaladas
Repositorios persistentes, base de datos, configuración y datos de aplicación	Copias de seguridad automáticas fuera del servidor
Recuperación del servicio después de un reinicio normal del VPS	Alta disponibilidad o conmutación por error automática
Características de colaboración estándar de Gitea	Runners gestionados, capacidad CI, SMTP, OAuth, LDAP o almacenamiento externo

La imagen no incluye repositorios de muestra, organizaciones, usuarios, runners, paquetes, credenciales de terceros, entrega de correo electrónico, un dominio o un certificado de confianza del navegador. Tampoco expone secretos de la aplicación en los detalles del recurso.

¿Cómo funciona la configuración segura del primer administrador?

El primer administrador se crea a través de una sesión SSH autenticada en el VPS, mientras que la página de instalación pública de Gitea permanece bloqueada. Esto previene la carrera común en la que un instalador web no inicializado es accesible desde internet y un visitante no intencionado completa la configuración primero.

La imagen de la aplicación prepara la base de datos y la configuración antes de la entrega. Habilita el bloqueo de instalación de Gitea y desactiva el registro público de usuarios. El comando de configuración del administrador luego ejecuta el comando administrativo oficial de Gitea dentro del entorno de la aplicación.

El proceso de configuración debe tener estas propiedades:

Solicita el nombre de usuario y el correo electrónico de manera interactiva.
Indica a la CLI oficial de Gitea que genere una contraseña aleatoria de 24 caracteres en lugar de colocar tu contraseña elegida en un argumento de línea de comandos.
Muestra la contraseña de un solo uso solo en la terminal SSH actual y no la escribe en el historial de la shell, un archivo o un registro.
Requiere un cambio de contraseña en el primer inicio de sesión web.
Se niega a crear otro administrador después de que ya existe el primer administrador.
No genera un token de acceso personal ni una clave SSH para ti.
No imprime los secretos internos de Gitea.

Después de iniciar sesión, revisa Administración del sitio y la política de registro de usuarios. El registro está desactivado por defecto para que los usuarios desconocidos de internet no puedan crear cuentas. Puedes crear usuarios aprobados desde la interfaz de administración o cambiar la política si el registro abierto es un requisito intencionado y tienes un plan de control de abusos.

No envíes la contraseña de un solo uso o la contraseña final del administrador a través de chat, un ticket o una transcripción de shell compartida. Cierra la sesión SSH inicial después de cambiar la contraseña. Agrega un segundo administrador solo cuando la propiedad operativa lo requiera, y usa una cuenta normal separada para el trabajo rutinario de Git cuando sea práctico.

¿Cómo difieren Git HTTPS y Git SSH?

Git HTTPS utiliza el punto final web de Gitea detrás de tu dominio HTTPS de confianza, mientras que Git SSH utiliza un servicio SSH dedicado de Gitea y una clave pública a nivel de cuenta. Ambos admiten operaciones normales de clonación, obtención, extracción y envío, pero su configuración de autenticación y transporte difiere.

Método	Patrón de dirección inicial	Autenticación	Mejor uso después de la configuración
Interfaz web inicial	`http://127.0.0.1:3000` a través de SSH Tunnel	Nombre de usuario y contraseña de Gitea	Primer inicio de sesión, cambio de contraseña y configuración privada
Interfaz web regular	`https://git.example.com`	Nombre de usuario y contraseña de Gitea	Navegación y administración de repositorios después de la configuración del dominio
Git HTTPS	`https://git.example.com/<owner>/<repo>.git`	Preferir un token de acceso personal para clientes Git	Transporte Git basado en web después de la configuración del dominio y HTTPS de confianza
Git SSH	`ssh://git@<server-ip>:2222/<owner>/<repo>.git`	Clave pública SSH añadida a la cuenta de Gitea	Conveniente para clientes Git de desarrolladores y automatización utilizando claves gestionadas
SSH del sistema VPS	Host y puerto específicos del recurso	Clave SSH del VPS o credencial del servidor actual	Administración del servidor y configuración del primer administrador, no acceso al repositorio

Para Git SSH:

Crea o elige una clave SSH en tu estación de trabajo.
Inicia sesión en Gitea y agrega la clave pública en la configuración de la cuenta.
Copia la dirección de clonación SSH desde la página del repositorio.
Verifica la huella digital del host en la primera conexión en lugar de aceptar una clave inesperada sin revisarla.
Mantén la clave privada en el cliente y protégela con permisos de archivo apropiados y, cuando sea adecuado, una frase de contraseña.

Gitea SSH Git no debería pedir la contraseña web de Gitea. El puerto 2222 pertenece al servicio de repositorio; no proporciona un shell de servidor.

Para Git HTTPS, crea un token de acceso personal con solo los permisos necesarios para ese cliente o integración. Evita poner un token directamente en un comando que permanecerá en el historial de la shell. Usa tu ayudante de credenciales de Git o un almacén de secretos apropiado para tu sistema operativo.

¿Por qué deberías agregar un dominio y HTTPS?

Un dominio y HTTPS de confianza del navegador protegen las credenciales web y el tráfico Git HTTPS y le dan a la instancia una identidad pública estable. La imagen mantiene el puerto 3000 en la interfaz de bucle invertido del VPS, por lo que el servicio web no es accesible públicamente hasta que configures deliberadamente un proxy inverso.

La guía oficial de proxy inverso de Gitea explica cómo Gitea opera detrás de proxies comunes. Una configuración de producción normalmente incluye:

Un registro DNS como git.example.com apuntando al VPS.
Un proxy inverso escuchando en los puertos 80 y 443.
Un certificado TLS de confianza del navegador para el dominio.
Una redirección de HTTP a HTTPS.
Encabezados de host, dirección del cliente y protocolo reenviados que coinciden con la configuración del proxy.
La ROOT_URL pública de Gitea y la configuración del dominio actualizadas a la URL HTTPS final.
SSH_DOMAIN y el puerto SSH mostrado actualizados para que las instrucciones de clonación del repositorio sigan siendo precisas.

Después de cambiar la dirección, verifica todo lo siguiente:

La página de inicio de sesión se carga sin una advertencia de certificado.
Los enlaces generados por Gitea utilizan el dominio HTTPS en lugar de la antigua dirección IP.
La clonación y el envío de Git HTTP funcionan a través de HTTPS.
Los enlaces de clonación SSH muestran el dominio y puerto correctos.
Los webhooks y las URL de callback de OAuth, si se configuran más tarde, utilizan la dirección pública prevista.
Los envíos grandes no fallan debido a límites de cuerpo o tiempo de espera del proxy inverso.

La imagen de la aplicación no registra el dominio ni emite el certificado por ti. Esos pasos son gestionados por el usuario porque el nombre de host final y la cuenta DNS pertenecen al propietario del sitio.

¿Cómo deberías organizar usuarios y acceso a repositorios?

Utiliza cuentas individuales, equipos de organización, permisos de repositorio, claves SSH y tokens con alcance en lugar de compartir una única identidad de administrador. Gitea puede alojar repositorios privados y públicos, pero el administrador debe decidir quién puede descubrir, leer, escribir, revisar y administrar cada recurso.

Una base práctica para un pequeño equipo es:

Mantener el registro público deshabilitado a menos que haya una razón deliberada para abrirlo.
Dar a cada persona una cuenta individual.
Reservar el acceso de administrador para propietarios del servidor y del servicio.
Crear organizaciones para repositorios relacionados y equipos para grupos de permisos.
Otorgar el menor permiso de repositorio necesario para cada rol.
Utilizar protección de ramas y reglas de revisión para ramas importantes.
Utilizar claves de implementación o tokens de acceso personal con alcance para la automatización en lugar de una contraseña de administrador.
Eliminar cuentas, claves y tokens de inmediato cuando el acceso ya no sea necesario.
Habilitar la autenticación de dos factores para usuarios privilegiados cuando se ajuste a tu modelo de acceso.
Revisar periódicamente la propiedad de organizaciones, repositorios, webhooks, OAuth y tokens.

Si más tarde conectas SMTP, OAuth, LDAP o OpenID Connect, trata eso como un cambio de producción separado. Prueba el enlace de cuentas, la recuperación, la desvinculación, el acceso del administrador y el comportamiento de fallos antes de confiar en la integración. La imagen base no incluye estos servicios ni sus credenciales.

¿Qué debe proteger una copia de seguridad de Gitea?

Una copia de seguridad completa de Gitea debe proteger la base de datos, los repositorios Git, la configuración, los secretos de la aplicación y cualquier adjunto, objeto LFS, paquete, lanzamiento, avatar u otros datos almacenados que utilice tu instancia. Copiar solo los repositorios Git no es suficiente para reconstruir usuarios, permisos, problemas, solicitudes de extracción, tokens, webhooks y configuraciones del servicio.

La documentación oficial de copia de seguridad y restauración de Gitea describe el flujo de trabajo gitea dump y advierte que el servicio contiene varias capas de datos que pueden cambiar juntas. Una copia de seguridad consistente requiere coordinación; una base de datos de aplicación que dice que una operación de repositorio se completó mientras que la copia del repositorio capturó un estado anterior puede producir un punto de recuperación incompleto.

Tu plan de copia de seguridad debe definir:

Capa	Ejemplos	Por qué es importante
Base de datos	Usuarios, permisos, problemas, solicitudes de extracción, configuraciones, tokens	Recrea el estado y las relaciones de la aplicación
Repositorios Git	Commits, ramas, etiquetas, objetos Git	Preserva el historial de origen
Configuración y secretos	URL pública, configuraciones del servicio, `SECRET_KEY`, tokens internos	Mantiene los datos cifrados legibles y el comportamiento consistente
Datos de la aplicación	Adjuntos, avatares, LFS, paquetes, activos de lanzamiento, índices	Preserva contenido fuera de los objetos Git normales
Procedimiento de recuperación	Versiones, propiedad, regeneración de hooks, pasos de verificación	Convierte archivos almacenados en un servicio restaurado utilizable

Almacena copias de recuperación fuera del VPS. Cifralas cuando contengan código fuente privado, credenciales, tokens, datos personales o configuración interna. Mantén más de un punto de recuperación, monitorea la finalización de la copia de seguridad y prueba una restauración en un entorno separado.

Un reinicio normal del VPS prueba la persistencia, no la recuperabilidad. No protege contra eliminación accidental, corrupción de repositorios, una actualización fallida, compromiso de credenciales, pérdida de sistema de archivos, eliminación del VPS o un atacante que elimina tanto los datos en vivo como los archivos de copia de seguridad locales.

Para la base más amplia de mantenimiento del servidor en torno a SSH, parches, monitoreo y propiedad de recuperación, consulta Gestión de VPS: Guía Práctica.

¿Cómo deberías actualizar Gitea?

Actualiza Gitea como un cambio de aplicación controlado: lee las notas de la versión, crea una copia de seguridad restaurable, preserva el tipo de implementación y verifica los repositorios y la autenticación después. La imagen utiliza un lanzamiento estable fijo en lugar de una etiqueta flotante, por lo que un reinicio no cambia silenciosamente la versión de la aplicación.

Antes de una actualización:

Lee las notas de lanzamiento y actualización de Gitea para las versiones de origen y destino.
Confirma la ruta de actualización compatible en lugar de saltar entre versiones sin revisión.
Crea y verifica una copia de seguridad fuera del servidor.
Registra la imagen de contenedor actual, la configuración, la URL pública, la configuración SSH y la propiedad del almacenamiento.
Planifica una ventana de mantenimiento porque las migraciones de base de datos o la consistencia de la copia de seguridad pueden requerir tiempo de inactividad.

Después de una actualización:

Confirma que el contenedor alcanza un estado saludable.
Inicia sesión con una cuenta normal y una cuenta de administrador.
Clona, extrae y envía a través de HTTP(S) y SSH.
Abre un problema y una solicitud de extracción en un repositorio de prueba.
Verifica webhooks, paquetes, LFS, correo electrónico e integraciones de autenticación que tu instancia realmente utiliza.
Verifica que las URL de clonación generadas aún utilicen el dominio y puerto correctos.
Confirma que los usuarios, repositorios, configuraciones y secretos sobrevivieron al cambio.

No cambies casualmente entre las disposiciones de contenedor con y sin root de Gitea; la documentación oficial de Docker señala que su comportamiento de almacenamiento y SSH difiere. Preserva el modelo de implementación seleccionado por la imagen de la aplicación a menos que tengas un plan de migración y retroceso.

¿Cuánta capacidad de VPS necesita Gitea?

La capacidad de Gitea depende de la concurrencia de usuarios, el número y tamaño de los repositorios, los patrones de operación de Git, los paquetes, LFS, indexación, automatización y requisitos de retención de datos. Elige un plan elegible en el flujo de compra, monitorea la carga de trabajo real y pasa a una configuración más grande cuando aparezca presión sostenida en CPU, memoria, disco o I/O.

El proyecto oficial de Gitea describe una instalación para un pequeño equipo como relativamente ligera, pero esa declaración no define la capacidad de cada carga de trabajo de repositorio. Los grandes monorepositorios, las clonaciones frecuentes, los activos binarios grandes, el almacenamiento de paquetes, la indexación de búsqueda y los trabajos automatizados pueden cambiar sustancialmente el perfil de recursos.

Carga de trabajo	Consideración de capacidad
Unos pocos repositorios de código fuente pequeños	Apropiado para una carga de validación de entrada
Pequeño equipo de desarrollo	Medir operaciones web y Git concurrentes
Gran historial de repositorio	Planificar espacio en disco, tiempo de copia de seguridad y tráfico de clonación
Git LFS o registro de paquetes	Planificar almacenamiento y transferencia por separado de los objetos Git normales
Muchos webhooks o integraciones	Monitorear colas, fallos y disponibilidad descendente
Acciones de Gitea	La capacidad del runner es separada y no está incluida por la imagen base
Base de datos externa o almacenamiento de objetos	Requiere una arquitectura diseñada y operada por separado

Observa la presión de memoria, la saturación de CPU, la capacidad del sistema de archivos, el uso de inodes, el comportamiento de bloqueo de SQLite, los reinicios de contenedores, la latencia de solicitudes, las operaciones de Git fallidas, la duración de la copia de seguridad y la duración de la restauración. La puerta de compra mínima es un punto de partida validado, no una promesa de repositorios o usuarios ilimitados.

Errores comunes a evitar

La mayoría de las fallas tempranas de Gitea provienen de tratar un servicio de repositorio preinstalado como una plataforma completamente administrada. Evita estos errores:

Dejar expuesto un asistente de instalación. Usa el flujo de configuración del administrador SSH y mantén habilitado el bloqueo de instalación.
Abrir el registro público sin un plan de abuso. Mantén el registro deshabilitado a menos que el registro abierto sea intencionado.
Exponer el puerto 3000 como HTTP público. Mantenlo en bucle invertido y agrega un dominio con HTTPS de confianza antes de usar la web y Git HTTPS de rutina.
Confundir el puerto 2222 con el acceso al shell del VPS. Es el punto final SSH Git de Gitea y no proporciona un shell de servidor.
Compartir una cuenta de administrador. Usa cuentas individuales y el principio de menor privilegio.
Poner tokens en el historial de la shell o en archivos de repositorio. Usa un almacén de credenciales o secretos apropiado.
Respaldar solo los repositorios Git. Protege la base de datos, la configuración, los secretos, los adjuntos, LFS, los paquetes y el procedimiento de recuperación también.
Mantener la única copia de seguridad en el mismo VPS. Almacena copias de recuperación cifradas fuera del servidor.
Usar una etiqueta de contenedor flotante. Fija el lanzamiento estable probado y actualiza deliberadamente.
Asumir que la capacidad mínima cubre CI o grandes binarios. Los runners, paquetes, LFS, monorepositorios y alta concurrencia requieren dimensionamiento separado.
Cambiar la URL pública sin actualizar Gitea. Verifica ROOT_URL, dominio, dominio SSH, enlaces de clonación, callbacks y webhooks.
Actualizar sin una prueba de restauración. Una copia de seguridad que nunca se ha restaurado es un plan de recuperación no verificado.

FAQ

¿Puedo autoalojar Gitea sin instalarlo manualmente?

Sí. La imagen de aplicación Gitea de VoyraCloud proporciona una instancia de Community Edition preinstalada en un Cloud VPS o Residential IP VPS elegible. Aún debes crear el primer administrador, configurar el acceso a los repositorios, conectar un dominio y HTTPS, gestionar usuarios y ser responsable de las actualizaciones y copias de seguridad.

¿Por qué se crea el primer administrador a través de SSH?

SSH mantiene el paso de creación del administrador detrás del acceso al VPS y previene que un visitante de internet reclame un asistente de instalación expuesto. La página de instalación pública está bloqueada antes de la entrega, y el comando de configuración se niega a crear otro administrador después de que ya existe uno.

¿Puedo exponer el puerto `3000` directamente a internet?

No. La aplicación vincula el puerto 3000 a la interfaz de bucle invertido del VPS y el primer inicio de sesión utiliza un SSH Tunnel. Conecta un dominio, configura un proxy inverso y HTTPS de confianza, y actualiza la configuración de URL pública de Gitea antes de publicar el servicio web.

¿Cuál es la diferencia entre SSH del VPS y Gitea SSH Git?

SSH del VPS administra el servidor Linux, mientras que Gitea SSH Git transfiere datos de repositorio utilizando claves adjuntas a cuentas de Gitea. El VPS utiliza el host y puerto SSH que se muestran para el recurso; Gitea SSH Git utiliza el usuario git y el puerto 2222.

¿Debería usar una contraseña o un token para Git HTTPS?

Usa un token de acceso personal con solo los permisos necesarios para el cliente o la integración. Almacénalo en un ayudante de credenciales apropiado en lugar de incrustarlo en un repositorio, script o entrada de historial de shell.

¿Está habilitado el registro de usuarios públicos?

No. La imagen de la aplicación desactiva el auto-registro por defecto. El administrador puede crear usuarios aprobados o cambiar deliberadamente la política de registro después de evaluar el abuso, la verificación de correo electrónico y los requisitos de control de acceso.

¿Incluye la imagen runners de Gitea Actions?

No. La imagen base no provisiona ni opera runners de Actions. La capacidad de ejecución de runners, aislamiento, secretos, acceso a la red y mantenimiento requieren un diseño separado.

¿Qué debo respaldar?

Protege la base de datos, los repositorios Git, la configuración, los secretos de la aplicación, los adjuntos, los objetos LFS, los paquetes, los lanzamientos y cualquier otro dato de aplicación almacenado. Mantén copias fuera del VPS y prueba una restauración completa.

¿VoyraCloud actualiza Gitea automáticamente?

No. Los nuevos recursos VPS reciben el lanzamiento estable aprobado para la imagen, mientras que cada propietario controla las actualizaciones posteriores. Lee las notas de actualización oficiales, crea una copia de seguridad restaurable y prueba los flujos de trabajo de Git y autenticación después de cada cambio.

¿Se requiere Residential IP VPS para Gitea?

No. Cloud VPS es la opción normal de propósito general para un servicio de código fuente. Residential IP VPS también está técnicamente soportado cuando una carga de trabajo más amplia necesita específicamente sus características de red, pero la identidad residencial no mejora el alojamiento Git normal por sí sola.

Conclusión

Autoalojar Gitea en un VPS otorga a los desarrolladores y pequeños equipos control sobre repositorios, cuentas, datos de colaboración, acceso a la red, actualizaciones y recuperación. La imagen de aplicación de VoyraCloud acorta la implementación inicial al entregar un entorno Gitea estable fijo con una página de instalación bloqueada, configuración privada del primer administrador, acceso Git HTTPS y SSH, y datos locales persistentes.

Esa base de partida aún necesita un propietario. Agrega HTTPS de confianza, utiliza cuentas individuales y credenciales con alcance, mantén el registro alineado con tu política de acceso, monitorea la capacidad, fija las actualizaciones y mantén copias de seguridad fuera del servidor probadas antes de tratar el servicio como infraestructura crítica.

Para la capa de dominio y proxy inverso frente al servicio, consulta la guía sobre Nginx Proxy Manager en un VPS.

Utiliza la imagen de aplicación de VoyraCloud para Gitea para comenzar desde un entorno VPS preinstalado mientras mantienes tu servicio de código fuente bajo tu control.