Aplicaciones

cipi app create

cipi app create admite dos tipos de aplicaciones: Laravel (predeterminado) y personalizado (--custom). Las aplicaciones Laravel obtienen un entorno completamente aislado: Usuario de Linux, grupo PHP-FPM o Laravel Octane (FrankenPHP) desde v5.0, Nginx vhost, base de datos (MariaDB por defecto; opcional PostgreSQL desde v4.8.0), Supervisor trabajador, entrada crontab, versiones de implementación sin tiempo de inactividad, SSH implementar clave y compilarse automáticamente .env. Las aplicaciones personalizadas son más sencillas: consulte aplicaciones personalizadas para más detalles.

Aplicación Laravel (predeterminada: PHP-FPM)

$ cipi app create

Laravel Octane (FrankenPHP)

$ cipi app create --octane
$ cipi app create --octane=frankenphp   # explicit (same as --octane)

Ver Laravel Octane para conocer los requisitos, la conversión y cómo vhost difiere del FPM.

No interactivo (banderas)

$ cipi app create \
    --user=myapp \
    --domain=myapp.com \
    --repository=git@github.com:you/myapp.git \
    --branch=main \
    --php=8.5

# Laravel Octane (FrankenPHP) — v5.0+
$ cipi app create --user=myapp --domain=myapp.com \
    --repository=git@github.com:you/myapp.git --octane

# optional PostgreSQL (v4.8.0+, after cipi db install pgsql)
$ cipi app create --user=myapp --domain=myapp.com \
    --repository=git@github.com:you/myapp.git --engine=pgsql

Aplicaciones

Laravel Octane (FrankenPHP)

desde v5.0, Laravel aplicaciones pueden servir HTTP a través de Laravel Octane con el FrankenPHP servidor en lugar de por aplicación PHP-Grupo de FPM. Octane y las aplicaciones FPM clásicas se ejecutan en paralelo en el mismo servidor Cipi.

Qué configura Cipi

• Asigna un puerto localhost en 8100–8999 y tiendas octane / octane_port en apps.json
• Nginx usos de host virtual proxy_pass a Octane y sirve archivos estáticos desde current/public — sin grupo de FPM por aplicación
• Supervisor programa ${app}-octane junto a los trabajadores de la cola
• Plantilla de implementación laravel-octane.php reinicia / recarga Octane en la implementación
• .env: OCTANE_SERVER=frankenphp, OCTANE_HTTPS=true

Requisitos de la aplicación

Su repositorio Laravel debe incluir laravel/octane y correr php artisan octane:install --server=frankenphp. Octane comienza después del primer implementación exitosa.

# create an Octane app
$ cipi app create --user=myapp --domain=myapp.com \
    --repository=git@github.com:you/myapp.git --octane

# convert an existing FPM app → Octane (or the reverse)
$ cipi app convert myapp --to=octane
$ cipi app convert myapp --to=fpm

# tune Octane workers (also see app limits)
$ cipi app limits myapp --octane-workers=4

cipi app convert --to=octane|fpm reescribe el pool /vhost / Supervisor / Deployer plantilla / .envy vuelve a aplicar SSL cuando ya hay un certificado presente.

cipi app create --custom

Crea un aplicación personalizada con implementación clásica (sin tiempo de inactividad cero): el código se implementa en htdocs - no current/shared enlaces simbólicos. Ideal para sitios estáticos, SPA (Vue, React, Svelte), WordPress, otros CMS o cualquier proyecto o marco que no sea Laravel PHP.

Durante la creación solo eliges la raíz del documento (predeterminado /, o por ej. www, dist, public). Nginx está preconfigurado con index index.html index.php, try_files $uri $uri/ /index.php?$args, y error_page 404 /404.html — no hay indicaciones para try_files o punto de entrada.

Git opcional (solo SFTP)

El repositorio de Git es opcional para aplicaciones personalizadas. Laravel Las aplicaciones aún requieren un repositorio. Si omite el repositorio para una costumbre aplicación, Cipi crea /home/<app>/htdocs con un marcador de posición index.html y hace no configurar una clave de implementación o webhook: carga archivos con SFTP (o SCP/rsync) a ~/htdocs como usuario de la aplicación. El resultado de incorporación explica esto "sin repositorio, solo SFTP" flujo de trabajo. Si proporciona un repositorio, el comportamiento no cambia: use cipi deploy <app> para introducir el código htdocs.

Qué incluye y qué agregas

Las aplicaciones personalizadas tienen sin base de datos, no .env, no cron y no trabajadores en cola. Cuando se configura un repositorio, se incluyen una clave de implementación y (con la configuración automática de Git) webhook. mostrado; para aplicaciones solo SFTP, se omiten. El resumen posterior a la creación enumera el acceso SSH y los siguientes pasos en consecuencia.

Si su aplicación personalizada necesita una base de datos (por ejemplo, WordPress, Drupal), cree una con cipi db create --name=<app> después del despliegue. Ver cipi bases de datos para realizar copias de seguridad, restaurar y administrar contraseñas.

Con Git: ejemplo no interactivo:

$ cipi app create --custom --user=mysite --domain=mysite.com \
    --repository=git@github.com:you/mysite.git --docroot=dist

Solo SFTP: omitir --repository y --branch:

$ cipi app create --custom --user=mysite --domain=mysite.com --docroot=dist

Con un repositorio, use cipi deploy <app> desplegar; El código se clona en /home/<app>/htdocs.

app list / app show / app edit / app delete

cipi app reverb

desde v5.0, habilitar Laravel Reverb para WebSockets propios en un Laravel aplicación. Cipi asigna un puerto de host local en 9000–9099, agrega el programa Supervisor ${app}-reverb, representantes Nginx /app a ese puerto, y escribe REVERB_* en .env.

$ cipi app reverb enable myapp
$ cipi app reverb status myapp
$ cipi app reverb disable myapp

cipi app clone

desde v5.0, clone una aplicación Laravel existente en una nueva aplicación de prueba (o revisión) con su propio dominio. Conjuntos cloned_from en apps.json; hace no copie webhook o git ID.

$ cipi app clone myapp --domain=staging.myapp.com
$ cipi app clone myapp --domain=staging.myapp.com --name=myapp-stg --branch=develop --with-db
$ cipi app clone myapp --domain=staging.myapp.com --no-db

cipi app limits

desde v5.0, establezca límites de recursos por aplicación con límites estrictos aplicados por Cipi.

$ cipi app limits myapp --fpm-max-children=20 --memory-limit=256M
$ cipi app limits myapp --octane-workers=4 --worker-procs=3
$ cipi app limits myapp   # show current limits

app suspend / app unsuspend

Disponible desde v4.5.8. Desconectar una aplicación sin eliminarla: útil para la facturación bodegas, ventanas de mantenimiento o sitios de preparación que desee que estén completamente a oscuras. La suspensión cambia el host virtual Nginx por una estática HTTP 503 página servida desde /var/www/cipi-suspended/.

$ cipi app suspend myapp      # take offline (503 page)
$ cipi app unsuspend myapp    # restore normal vhost

Comportamiento

• HTTPS incluido — certbot clona el vhost de suspensión en el :443 bloquear, por lo que HTTPS también muestra la página sin conexión
• Let's Encrypt todavía funciona — el /.well-known/acme-challenge/ camino permanece público para que los certificados se puedan emitir o renovar mientras están suspendidos
• Sobrevive a la regeneración del vhost — cambios de alias, PHP ediciones e SSL instalaciones respetar la bandera suspendida
• Visible en listados — cipi app list marca aplicaciones suspendidas; cipi domains añade ⏸ suspended en cada fila

También disponible a través del DESCANSO API (POST /api/apps/{name}/suspend), cipi-cli (apps suspend), y el módulo WHMCS (Suspender / Botones de reactivación). Requiere habilidad simbólica apps-suspend para API acceso.

cipi basicauth

Disponible desde v4.5.2. Proteja cualquier aplicación (Laravel o personalizada) detrás de un Nginx solicitud de nombre de usuario/contraseña. Útil para preparar sitios, herramientas internas o aplicaciones que no están listas para tráfico público todavía.

Las credenciales están codificadas con openssl passwd -apr1 (no apache2-utils necesario) y almacenado en /etc/nginx/cipi-basicauth/<app>.htpasswd; el estado habilitado vive en apps.json. el auth_basic Las directivas se inyectan por location bloque, por lo que la protección sobrevive a la regeneración de vhost (cambios de alias, ediciones PHP) y se clona en el :443 bloquear por certbot — HTTPS también está cubierto. Los desafíos de ACME permanecen público, por lo que la emisión y renovación de certificados nunca se bloquean. La autenticación básica se elimina automáticamente en cipi app delete.

Gestión de variables ENV

cada Laravel la aplicación tiene un solo .env archivo viviendo en /home/<app>/shared/.env. Las aplicaciones personalizadas no tienen .env. Lo crea y lo completa previamente Cipi durante app create con la base de datos credenciales, APP_KEY, APP_URL, configuración de caché/sesión/cola y la webhook token. el shared/ El directorio tiene un enlace simbólico en cada versión, por lo que lo mismo .env siempre está activo independientemente de qué versión esté vigente.

Edite interactivamente a través de CLI

La forma más segura de cambiar los valores ENV es a través del propio Cipi: abre el archivo en nano como aplicación usuario, con los permisos correctos:

$ cipi app env myapp

Ahorra con Ctrl+O luego sal con Ctrl+X. Los cambios entran en vigor inmediatamente para los nuevos solicitudes: no es necesario reiniciar para la mayoría de los valores. Si cambia la conexión de la cola o el controlador de caché, reiniciar a los trabajadores:

$ cipi worker restart myapp

Banderas no interactivas (v5.0.3+)

desde v5.0.3, scripts, el panel API y la web GUI pueden gestionar.env sin abrir un editor:

$ cipi app env myapp --show
$ cipi app env myapp --show --json
$ cipi app env myapp --get=APP_URL
$ cipi app env myapp --set=APP_DEBUG=false
$ cipi app env myapp --unset=LEGACY_KEY

DESCANSO: GET|PUT /api/apps/{name}/env (capacidad apps-env, API 1.14+). MCP: AppEnvShow, AppEnvUpdate.

Editar directamente a través de SSH

También puedes editar el archivo directamente a través de SSH como root o como usuario de la aplicación:

# as root
$ nano /home/myapp/shared/.env

# or switch to the app user first
$ su - myapp
$ nano ~/shared/.env

Variables ENV clave establecidas por Cipi

Agregando tus propias variables

Agregue cualquier variable personalizada al final del archivo como lo haría normalmente en un proyecto Laravel. ellos se conservan en todas las implementaciones porque .env vive en shared/ y es nunca sobrescrito por Deployer.

# your custom variables
STRIPE_KEY=sk_live_...
STRIPE_SECRET=sk_live_...
MAIL_MAILER=smtp
MAIL_HOST=smtp.mailgun.org

cipi app run

desde v5.0.3, ejecutar un incluido en la lista blanca no interactivo comando como la aplicación usuario: útil desde CLI, panel API y web GUI “Comandos de aplicación”. Editores, buscapersonas, shells y Los REPL están bloqueados (nano, vim, less, bash, tinker,…). Banderas interactivas (p. ej. tail -f, php -a) son rechazado.

$ cipi app run myapp composer install --no-dev
$ cipi app run myapp npm ci
$ cipi app run myapp ls -la shared
$ cipi app run --commands          # list allowed binaries
$ cipi app run --commands --json

Los binarios permitidos incluyen composer, npm/npx/yarn/pnpm, ls/ll, cat/head/tail, sistema de archivos ayudantes, archivos, git, php, node, y find. DESCANSO: POST /api/apps/{name}/run (trabajo asíncrono, capacidad apps-run) y GET /api/run-commands (API 1.14+). MCP: AppRun, AppRunCommands.

cipi app logs

La aplicación Tail registra en tiempo real. Los troncos se rotan diariamente y se conservan durante 14 días. Por De forma predeterminada, se muestran todos los registros, incluidos Laravel registros diarios. (laravel-YYYY-MM-DD.log) de shared/storage/logs/.

$ cipi app logs myapp                  # all logs (incl. Laravel daily logs)
$ cipi app logs myapp --type=nginx     # Nginx access + error
$ cipi app logs myapp --type=php       # PHP-FPM errors
$ cipi app logs myapp --type=worker    # queue worker output
$ cipi app logs myapp --type=deploy    # deploy history
$ cipi app logs myapp --type=laravel   # Laravel application logs

app artisan & app tinker

Ejecute los comandos Artisan y Tinker como usuario de la aplicación con la versión PHP correcta y open_basedir contexto, exactamente como se ejecutarían durante una implementación.

$ cipi app artisan myapp migrate:status
$ cipi app artisan myapp queue:retry all
$ cipi app artisan myapp db:seed --class=ProductionSeeder
$ cipi app artisan myapp cache:clear
$ cipi app tinker myapp

SSH como usuario de la aplicación

Cada aplicación se ejecuta bajo su propio usuario de Linux aislado. A veces necesitas trabajar directamente dentro de eso. entorno del usuario: inspeccionar archivos, ejecutar scripts únicos o depurar algo que solo se reproduce como el usuario correcto.

Directo SSH como usuario de la aplicación (recomendado)

Los usuarios de la aplicación pueden conectarse mediante SSH directamente al servidor con la contraseña generada en el momento de la creación de la aplicación:

# connect as the app user (password auth)
$ ssh myapp@your-server-ip

# you are directly inside the app user's shell
myapp@server:~$ pwd
/home/myapp

myapp@server:~$ cd ~/current
myapp@server:~$ ls

La contraseña se muestra cuando se crea la aplicación (o usa cipi app reset-password myapp a regenerarlo). Esto funciona para clientes SFTP, sesiones remotas IDE y acceso a terminales.

A través de cipi (ruta de administrador)

Si ya estás conectado como cipi, puedes cambiar directamente a cualquier usuario de la aplicación:

$ ssh cipi@your-server-ip
cipi@server:~$ sudo su - myapp

myapp@server:~$ pwd
/home/myapp

Restablecer la contraseña de usuario de la aplicación

Si necesita regenerar la contraseña de un usuario de la aplicación (por ejemplo, para SSH o SFTP directo), utilice:

$ cipi app reset-password myapp

La nueva contraseña se muestra en la pantalla; guárdela inmediatamente.

Comandos útiles una vez que haya iniciado sesión como usuario de la aplicación

# navigate to the active release
myapp@server:~$ cd ~/current

# run artisan directly with the correct PHP version
myapp@server:~$ /usr/bin/php8.5 ~/current/artisan tinker

# inspect the shared .env
myapp@server:~$ cat ~/shared/.env

# tail all logs
myapp@server:~$ tail -f ~/logs/*.log

# check active releases (ll is a built-in alias for ls -al)
myapp@server:~$ ll ~/releases/

Cada usuario de la aplicación .bashrc define una práctica ll='ls -al' alias (desde v4.5.5) para listados de directorios más rápidos a través de SSH, junto con el deploy y composer atajos. Las aplicaciones creadas antes de 4.5.5 reciben la ll alias automáticamente en el siguiente cipi self-update a través del 4.5.5 migración.