Automazione

Scrivilo una volta, eseguilo ovunque

Q: Meglio l'URL di deploy, la CLI o l'API?

L'URL di deploy è il più semplice: un solo `curl -X POST`, nessun token, ma la tua pipeline non sa se il deploy è riuscito. La CLI con `--watch` aspetta e fa fallire il job se il deploy fallisce. L'API ti offre lo stesso nei tuoi script.

Avvia i deploy dalla tua pipeline e fai fallire la build quando falliscono. Esegui lo stesso script bash su ogni server con un clic e informa i tuoi sistemi di ogni deploy.

Inizia il deploy Leggi la documentazione

Quattro modi per avviare un deploy senza cliccare

Push to deploy
Collega un repository GitHub, GitLab o Bitbucket e il webhook viene aggiunto per te. I push sul branch del sito avviano il deploy; gli altri branch vengono ignorati.
URL di deploy
Un POST a un URL segreto, senza token. Risponde 202, 409 se un deploy è già in corso, oppure 422. Puoi rigenerarlo in qualsiasi momento.
CLI di deploy
deploy deploy shop.example.com --watch avvia il deploy, ne mostra l'output in tempo reale e termina con il suo esito.
API REST
Crea un deployment con POST, poi segui la sua attività finché riesce o fallisce. JSON in entrata, JSON in uscita, 120 richieste al minuto per token.

CLI

Deploy da GitHub Actions in un solo step

La CLI è un singolo file PHP senza dipendenze, che scarichi dal tuo indirizzo Vimonto Deploy su /cli/deploy. I runner Ubuntu di GitHub hanno già PHP, quindi non c'è nulla da installare.

Crea un token con il solo ambito Deploy e salvalo come secret. Con --watch, un deploy fallito fa diventare rossa la pipeline. Lo stesso comando funziona in GitLab CI.

.github/workflows/deploy.yml

name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy shop.example.com
        run: php bin/deploy deploy shop.example.com --watch
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
          DEPLOY_URL: https://deploy.example.com
          DEPLOY_ORG: acme

API REST

Un'API per i tuoi script

I token API personali agiscono come te: possono fare ciò che il tuo ruolo consente, sui server che i tuoi team ti assegnano, entro gli ambiti che scegli. Lettura consulta, Deploy avvia e segue i deploy per la CI, e Scrittura crea e rimuove anche database ed esegue backup e ricette. I token scadono dopo 30, 90 o 365 giorni, oppure mai, e ne viene salvato solo l'hash.

Il lavoro lungo gira come attività che puoi interrogare con GET /tasks/<id> per stato, step, avanzamento e output. Gli errori sono JSON con un messaggio, e le risposte 409 riportano l'ID dell'attività in corso.

Elenca server, siti e deployment; trova un sito dal suo dominio
Avvia deploy e segui le loro attività
Crea ed elimina database
Elenca i backup ed eseguine uno subito
Elenca le ricette ed eseguine una su più server

Riferimento API

MCP

Lascia che il tuo assistente IA faccia il deploy

Vimonto Deploy ha un server MCP integrato, così assistenti come Claude Code, Claude Desktop, Cursor e VS Code possono elencare i tuoi server e siti, fare il deploy di un sito e seguirlo, leggere l’output di un’attività fallita, creare database ed eseguire backup e ricette.

Accede con un token API personale: l’assistente può fare esattamente ciò che consentono gli scope del token e il tuo ruolo, sui server a cui hai accesso. Tramite il server MCP non si può eliminare nulla.

Collega un assistente

Ricette

Script bash salvati per ogni server

Una ricetta è uno script bash che scrivi una volta ed esegui su uno o più server attivi, come root o come utente del server. Ogni server ha la sua attività, così segui ogni output separatamente, e puoi ricevere un unico report via email quando tutti hanno finito.

Variabili come {{server_name}}, {{ip_address}}, {{private_ip_address}} e {{server_type}} vengono compilate per ogni server subito prima che lo script parta.

Ricetta: libera spazio su disco

set -e
echo "Cleaning up on {{server_name}} ({{ip_address}})"
apt-get autoremove -y
journalctl --vacuum-time=14d
df -h /

Hook di deploy

Informa i tuoi sistemi di ogni deploy

Attiva l'Hook di deploy di un sito e Vimonto Deploy invia un POST con JSON al tuo endpoint HTTPS dopo ogni deploy, riuscito o fallito, senza rallentare il deploy. Usalo per un chat bot, un changelog o uno strumento di automazione, e usa Prova l'hook di deploy per verificarlo.

Preferisci l'email? Aggiungi fino a 10 indirizzi, anche esterni all'organizzazione, che ricevono un'email ogni volta che un deploy del sito fallisce.

Payload dell'hook di deploy (abbreviato)

{
    "event": "deployment.succeeded",
    "site": { "id": 12, "domain": "shop.example.com" },
    "server": { "id": 3, "name": "web-1" },
    "deployment": {
        "status": "succeeded",
        "branch": "main",
        "commit_message": "Fix the checkout total"
    }
}

Domande sull'automazione

Meglio l'URL di deploy, la CLI o l'API?

L'URL di deploy è il più semplice: un solo curl -X POST, nessun token, ma la tua pipeline non sa se il deploy è riuscito. La CLI con --watch aspetta e fa fallire il job se il deploy fallisce. L'API ti offre lo stesso nei tuoi script.

Posso creare server o siti tramite l'API?

Non ancora. L'API legge server, siti, deployment, database, backup, ricette e attività; avvia deploy; crea e rimuove database; ed esegue backup e ricette.

Di cosa ha bisogno la CLI?

PHP 8.2 o successivo con l'estensione curl, e un token API. Funziona su macOS, Linux e WSL, e non richiede accesso SSH ai tuoi server: parla solo con l'API via HTTPS.

Perché la mia pipeline riceve un 409?

Era già in corso un deploy del sito, spesso perché l'ha avviato il push to deploy. Disattiva Deploy a ogni push per i siti distribuiti dalla CI.

Chi può eseguire le ricette?

Proprietari, amministratori, manager e sviluppatori. I membri limitati ai propri team possono eseguire ricette solo sui propri server. Vedi sicurezza e team.

Il tuo prossimo deploy potrebbe essere online prima che finisca il caffè.

Crea un’organizzazione, collega un server e fai push. Tutto qui.