Autoalojamiento

Puede ejecutar el banco de trabajo de Oloproof en su propio servidor: en sus instalaciones, en una nube privada o con un proveedor de nube canadiense. El paquete de deploy/self-hosted/ ejecuta las mismas dos imágenes que oloproof.com (web y worker) y PostgreSQL, descargadas por digest. Sus datos se quedan donde lo ejecute, y no se envía nada a Oloproof.

Requisitos

• Un host Linux con Docker Engine y el plugin Compose. 4 GB de memoria y 2 CPU bastan para un equipo; el worker está limitado a 1,5 GB y la web a 768 MB.
• Disco para PostgreSQL. Cada ejecución que envíe se guarda allí.
• Un proxy inverso para HTTPS (Caddyfile.example es un ejemplo funcional; nginx también sirve).
• Acceso a ghcr.io/etobicoke/oloproof, o las imágenes copiadas en su propio registro.

Instalación

cd deploy/self-hosted
sh generate-env.sh          # writes .env and fills every secret

Defina OLOPROOF_WEB_IMAGE, OLOPROOF_WORKER_IMAGE (ambos digests ...@sha256:) y OLOPROOF_PUBLIC_URL en .env, y al menos una forma de iniciar sesión: correo para las cuentas con contraseña (OLOPROOF_MAIL_FROM con OLOPROOF_SMTP_URL u OLOPROOF_RESEND_API_KEY) o un proveedor OAuth. La web se niega a arrancar sin una. Después, iníciela:

docker compose --env-file .env up -d
curl -fsS http://127.0.0.1:3000/api/health

El servicio migrate actualiza la base de datos antes de que arranquen la web y el worker. El registro es por invitación, emitida con OLOPROOF_OPERATOR_TOKEN (deploy/README.md, «Signup»).

Configuración

.env.example enumera todas las variables que leen la web y el worker, cada una marcada como obligatoria, generada u opcional. Una variable opcional vacía desactiva su función. Conserve los secretos generados: una nueva contraseña de base de datos le deja sin acceso a la base, y una nueva clave de firma inicia un nuevo firmante. Un paquete autoalojado no tiene facturación, así que cada espacio de trabajo tiene los recuentos mensuales de casos del nivel gratuito; aumente OLOPROOF_FREE_TIER_PUSHED_MONTHLY y OLOPROOF_FREE_TIER_MANAGED_MONTHLY para su equipo.

Sin red saliente por defecto

La pila no envía telemetría ni llama a ningún servicio de Oloproof. Solo accede a la red para lo que usted active: el correo (un relé SMTP dentro de su red, o Resend), el inicio de sesión OAuth, Turnstile y los proveedores de modelos para los que un espacio de trabajo guarda una clave. Sin ninguno de ellos, funciona sin ruta hacia el exterior. Para un host aislado, copie las tres imágenes en su propio registro y apunte las variables de imagen a él. Las cuentas con contraseña necesitan correo, así que en una red aislada defina OLOPROOF_SMTP_URL con un relé dentro de ella.

Copias de seguridad

sh backup.sh /srv/backups/oloproof

backup.sh escribe un pg_dump comprimido en el directorio que elija. Prográmelo con cron o un temporizador de systemd, y copie usted mismo el directorio fuera del host. El script muestra el comando de restauración.

El volcado no incluye .env, y .env guarda OLOPROOF_CONTENT_KEY y los demás secretos generados: sin él, una base de datos restaurada no puede leer su contenido cifrado. Haga copia de .env al crearlo y cada vez que lo cambie, aparte de los volcados y fuera de línea (un gestor de contraseñas o un disco cifrado), nunca junto a ellos.

Actualizaciones

Escriba los dos digests de la nueva versión en .env y ejecute:

sh upgrade.sh /srv/backups/oloproof

Hace la copia de seguridad, descarga, migra y reinicia la web y el worker. Cuente con una breve interrupción. Para volver atrás, escriba los digests anteriores y restaure la copia que hizo.

Qué se admite

• Un solo host. No hay alta disponibilidad: la pila está tan disponible como su máquina.
• La residencia de los datos es donde lo ejecute. Oloproof no guarda ninguno de sus datos.
• Sin publicaciones sin tiempo de inactividad. Son exclusivas del servicio alojado.
• El paquete se comprueba con deploy/self-hosted/check.sh, que lo arranca con su propio nombre de proyecto, espera a /api/health, obtiene las páginas públicas y lo elimina.