Applications

cipi app create

cipi app create prend en charge deux types d'applications : Laravel (par défaut) et Personnalisé (--custom). Les applications Laravel bénéficient d'un environnement entièrement isolé : Utilisateur Linux, pool PHP-FPM ou Laravel Octane (FrankenPHP) depuis v5.0, Nginx vhost, base de données (MariaDB par défaut ; facultatif PostgreSQL depuis v4.8.0), Supervisor Worker, entrée crontab, versions de déploiement sans temps d'arrêt, SSH clé de déploiement et compilation automatique .env. Les applications personnalisées sont plus simples – voir applications personnalisées pour plus de détails.

Application Laravel (par défaut : PHP-FPM)

$ cipi app create

Laravel Octane (FrankenPHP)

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

Voir Laravel Octane pour les exigences, la conversion et comment le vhost diffère du FPM.

Non interactif (drapeaux)

$ 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

Applications

Laravel Octane (FrankenPHP)

Depuis v5.0, Laravel applications peuvent servir HTTP via Laravel Octane avec le FrankenPHP serveur au lieu d'un par application Piscine PHP-FPM. Octane et les applications FPM classiques s'exécutent côte à côte sur le même serveur Cipi.

Ce que Cipi configure

• Alloue un port localhost dans 8100–8999 et magasins octane / octane_port dans apps.json
• Nginx vhost utilise proxy_pass à Octane et sert les fichiers statiques de current/public — pas de pool FPM par application
• Programme Supervisor ${app}-octane aux côtés des travailleurs de la file d'attente
• Modèle de déploiement laravel-octane.php redémarre/recharge Octane lors du déploiement
• .env: OCTANE_SERVER=frankenphp, OCTANE_HTTPS=true

Exigences de l'application

Votre référentiel Laravel doit inclure laravel/octane et courir php artisan octane:install --server=frankenphp. Octane commence après le premier déploiement réussi.

# 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 réécrit le pool / vhost / Supervisor / Deployer modèle / .env, et réapplique SSL lorsqu'un certificat est déjà présent.

cipi app create --custom

Crée un application personnalisée avec déploiement classique (pas de temps d'arrêt nul) : le code est déployé dans htdocs — non current/shared liens symboliques. Idéal pour les sites statiques, SPA (Vue, React, Svelte), WordPress, autres CMS ou tout projet ou framework non Laravel PHP.

Lors de la création, vous choisissez uniquement la racine du document (par défaut /, ou par ex. www, dist, public). Nginx est préconfiguré avec index index.html index.php, try_files $uri $uri/ /index.php?$args, et error_page 404 /404.html - aucune invite pour try_files ou point d'entrée.

Git facultatif (SFTP uniquement)

Le dépôt Git est facultatif pour les applications personnalisées. Laravel les applications nécessitent toujours un référentiel. Si vous ignorez le référentiel pour un application, Cipi crée /home/<app>/htdocs avec un espace réservé index.html et fait ne configurez pas de clé de déploiement ou webhook — vous téléchargez des fichiers avec SFTP (ou SCP/rsync) à ~/htdocs en tant qu'utilisateur de l'application. La sortie d'intégration explique ce "pas de dépôt - SFTP uniquement" flux de travail. Si vous fournissez un référentiel, le comportement reste inchangé : utilisez cipi deploy <app> pour extraire le code htdocs.

Ce qui est inclus et ce que vous ajoutez

Les applications personnalisées ont pas de base de données, non .env, non cron et non travailleurs de la file d'attente. Lorsqu'un référentiel est configuré, une clé de déploiement et (avec la configuration automatique de Git) webhook sont montré ; pour les applications SFTP uniquement, celles-ci sont omises. Le résumé post-création répertorie l'accès SSH et les éléments suivants étapes en conséquence.

Si votre application personnalisée nécessite une base de données (par exemple WordPress, Drupal), créez-en une avec cipi db create --name=<app> après le déploiement. Voir cipi dB pour la sauvegarde, la restauration et la gestion des mots de passe.

Avec Git — exemple non interactif :

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

SFTP uniquement : omettre --repository et --branch:

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

Avec un référentiel, utilisez cipi deploy <app> déployer; le code est cloné dans /home/<app>/htdocs.

app list / app show / app edit / app delete

cipi app reverb

Depuis v5.0, activez Laravel Reverb pour les WebSockets propriétaires sur un Application Laravel. Cipi alloue un port localhost dans 9000–9099, ajoute le programme Supervisor ${app}-reverb, procurations Nginx /app à ce port, et écrit REVERB_* dans .env.

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

cipi app clone

Depuis v5.0, clonez une application Laravel existante dans une nouvelle application de préparation (ou de révision) avec son propre domaine. Ensembles cloned_from dans apps.json; fait pas copiez webhook ou les identifiants git.

$ 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

Depuis v5.0, définissez des limites de ressources par application avec des plafonds stricts appliqués par 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 depuis v4.5.8. Mettre une application hors ligne sans la supprimer : utile pour la facturation les retenues, les fenêtres de maintenance ou les sites de préparation que vous souhaitez complètement sombres. La suspension remplace le vhost Nginx par un statique HTTP 503 page servie à partir de /var/www/cipi-suspended/.

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

Comportement

• HTTPS inclus — certbot clone le vhost suspendu dans le :443 bloquer, donc HTTPS affiche également la page hors ligne
• Let's Encrypt fonctionne toujours — le /.well-known/acme-challenge/ chemin reste public afin que les certificats puissent être délivrés ou renouvelés pendant leur suspension
• Survit à la régénération du vhost — changements d'alias, modifications PHP et installations SSL respecter le drapeau suspendu
• Visible dans les annonces — cipi app list marque les applications suspendues ; cipi domains ajoute ⏸ suspended sur chaque ligne

Également disponible via le REPOS API (POST /api/apps/{name}/suspend), cipi-cli (apps suspend), et le Module WHMCS (Suspendre / Réactiver les boutons). Nécessite une capacité de jeton apps-suspend pour l'accès API.

cipi basicauth

Disponible depuis v4.5.2. Protégez n'importe quelle application (Laravel ou personnalisée) derrière un Nginx invite de nom d'utilisateur/mot de passe. Utile pour les sites de test, les outils internes ou les applications qui ne sont pas prêtes à être utilisées. circulation publique.

Les informations d'identification sont hachées avec openssl passwd -apr1 (non apache2-utils nécessaire) et stocké dans /etc/nginx/cipi-basicauth/<app>.htpasswd; l'État activé vit dans apps.json. Le auth_basic les directives sont injectées par location bloquer, donc la protection survit à la régénération du vhost (changements d'alias, modifications PHP) et est clonée dans le :443 bloquer par certbot — HTTPS est également couvert. Les défis de l'ACME restent public, de sorte que la délivrance et le renouvellement des certificats ne sont jamais bloqués. L'authentification de base est automatiquement supprimée cipi app delete.

Gestion des variables ENV

Chaque Laravel l'application a un seul .env dossier vivant à /home/<app>/shared/.env. Les applications personnalisées n'ont pas .env. Il est créé et pré-rempli par Cipi lors app create avec la base de données informations d'identification, APP_KEY, APP_URL, les paramètres de cache/session/file d'attente et les Jeton webhook. Le shared/ Le répertoire est lié symboliquement à chaque version, donc le même .env est toujours actif quelle que soit la version actuelle.

Modifier de manière interactive via CLI

Le moyen le plus sûr de modifier les valeurs ENV consiste à utiliser Cipi lui-même : il ouvre le fichier dans nano en tant qu'application. utilisateur, avec les autorisations appropriées :

$ cipi app env myapp

Économisez avec Ctrl+O puis sortez avec Ctrl+X. Les modifications prennent effet immédiatement pour les nouveaux requêtes – aucun redémarrage n’est nécessaire pour la plupart des valeurs. Si vous modifiez la connexion à la file d'attente ou le pilote de cache, redémarrez les travailleurs :

$ cipi worker restart myapp

Indicateurs non interactifs (v5.0.3+)

Depuis v5.0.3, les scripts, le panneau API et le web GUI peuvent gérer.env sans ouvrir un éditeur :

$ 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

REPOS : GET|PUT /api/apps/{name}/env (capacité apps-env, PHP 1.14+). MCP : AppEnvShow, AppEnvUpdate.

Modifier directement via SSH

Vous pouvez également modifier le fichier directement via SSH en tant qu'utilisateur root ou en tant qu'utilisateur de l'application :

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

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

Variables ENV clés définies par Cipi

Ajouter vos propres variables

Ajoutez n'importe quelle variable personnalisée au bas du fichier comme vous le feriez normalement dans un projet Laravel. Ils sont préservés à travers les déploiements car les .env vit dans shared/ et est jamais écrasé par Deployer.

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

cipi app run

Depuis v5.0.3, exécutez un liste blanche non interactive commande comme application utilisateur — utile à partir du CLI, du panneau API et du Web GUI « Commandes de l'application ». Éditeurs, pagers, shells et Les REPL sont bloqués (nano, vim, less, bash, tinker,…). Indicateurs interactifs (par ex. tail -f, php -a) sont rejeté.

$ 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

Les binaires autorisés incluent composer, npm/npx/yarn/pnpm, ls/ll, cat/head/tail, système de fichiers aides, archives, git, php, node, et find. REPOS : POST /api/apps/{name}/run (travail asynchrone, capacité apps-run) et GET /api/run-commands (PHP 1.14+). MCP : AppRun, AppRunCommands.

cipi app logs

Enregistrez les journaux des applications en temps réel. Les journaux sont alternés quotidiennement et conservés pendant 14 jours. Par par défaut, tous les journaux sont affichés, y compris les journaux quotidiens Laravel (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

Exécutez les commandes Artisan et Tinker en tant qu'utilisateur de l'application avec la version PHP correcte et open_basedir contexte - exactement comme ils s'exécuteraient lors d'un déploiement.

$ 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 en tant qu'utilisateur de l'application

Chaque application s'exécute sous son propre utilisateur Linux isolé. Parfois, vous devez travailler directement à l'intérieur de cela l'environnement de l'utilisateur : inspectez les fichiers, exécutez des scripts ponctuels ou déboguez quelque chose qui ne se reproduit que sous forme de le bon utilisateur.

SSH direct en tant qu'utilisateur de l'application (recommandé)

Les utilisateurs de l'application peuvent se connecter directement en SSH au serveur avec le mot de passe généré lors de la création de l'application :

# 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

Le mot de passe est affiché lors de la création de l'application (ou lors de l'utilisation cipi app reset-password myapp à le régénérer). Cela fonctionne pour les clients SFTP, les sessions à distance IDE et l'accès aux terminaux.

Via cipi (chemin d'accès administrateur)

Si vous êtes déjà connecté en tant que cipi, vous pouvez passer directement à n'importe quel utilisateur de l'application :

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

myapp@server:~$ pwd
/home/myapp

Réinitialiser le mot de passe de l'utilisateur de l'application

Si vous devez régénérer le mot de passe d'un utilisateur d'application (par exemple pour SSH ou SFTP direct), utilisez :

$ cipi app reset-password myapp

Le nouveau mot de passe s'affiche à l'écran — enregistrez-le immédiatement.

Commandes utiles une fois connecté en tant qu'utilisateur de l'application

# 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/

Celui de chaque utilisateur de l'application .bashrc définit un pratique ll='ls -al' pseudonyme (depuis v4.5.5) pour un listage plus rapide des répertoires via SSH, aux côtés du deploy et composer raccourcis. Les applications créées avant 4.5.5 reçoivent le ll alias automatiquement au prochain cipi self-update via le 4.5.5 migration.