Automatisering

Eén keer scripten, overal uitvoeren

Q: Gebruik ik de deploy-URL, de CLI of de API?

De deploy-URL is het eenvoudigst: één `curl -X POST`, zonder token, maar je pipeline weet dan niet of de deploy is gelukt. De CLI met `--watch` wacht en laat de job falen bij een mislukte deploy. De API geeft je hetzelfde in je eigen scripts.

Start deploys vanuit je pipeline en laat de build falen als de deploy faalt. Draai hetzelfde bash-script met één klik op elke server, en laat je eigen systemen weten wanneer er gedeployd is.

Begin met deployen Lees de documentatie

Vier manieren om te deployen zonder te klikken

Push to deploy
Koppel een repository van GitHub, GitLab of Bitbucket en er wordt automatisch een webhook toegevoegd. Pushes naar de branch van de site worden gedeployd; andere branches worden genegeerd.
Deploy-URL
Eén POST naar een geheime URL, zonder token. Het antwoord is 202, 409 als er al een deploy draait, of 422. Genereer hem wanneer je wilt opnieuw.
Deploy-CLI
deploy deploy shop.example.com --watch start de deploy, streamt de uitvoer en stopt met het resultaat ervan.
REST API
POST een deployment en volg de taak tot die slaagt of mislukt. JSON erin, JSON eruit, 120 requests per minuut per token.

CLI

Deployen vanuit GitHub Actions in één stap

De CLI is één PHP-bestand zonder dependencies, te downloaden vanaf je Vimonto Deploy-adres op /cli/deploy. De Ubuntu-runners van GitHub hebben PHP al, dus je hoeft niets te installeren.

Maak een token met alleen de scope Deploy en sla het op als secret. Met --watch kleurt een mislukte deploy de pipeline rood. Hetzelfde commando werkt 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

REST API

Een API voor je eigen scripts

Persoonlijke API-tokens handelen namens jou: ze kunnen wat je rol toestaat, op de servers die je teams je geven, binnen de scopes die je kiest. Lezen bekijkt, Deploy start en volgt deploys voor CI, en Schrijven maakt en verwijdert ook databases en draait back-ups en recepten. Tokens verlopen na 30, 90 of 365 dagen, of nooit, en alleen een hash wordt opgeslagen.

Langer werk draait als een taak die je met GET /tasks/<id> kunt opvragen voor de status, stap, voortgang en uitvoer. Fouten zijn JSON met een bericht, en 409-antwoorden bevatten de ID van de taak die al draait.

Servers, sites en deployments opvragen; een site vinden op zijn domein
Deploys starten en hun taken volgen
Databases aanmaken en verwijderen
Back-ups opvragen en er direct een draaien
Recepten opvragen en er een op meerdere servers draaien

API-referentie

MCP

Laat je AI-assistent deployen

Vimonto Deploy heeft een ingebouwde MCP-server, zodat assistenten zoals Claude Code, Claude Desktop, Cursor en VS Code je servers en sites kunnen opvragen, een site kunnen deployen en de deploy volgen, de uitvoer van een mislukte taak lezen, databases aanmaken en back-ups en recepten uitvoeren.

Hij logt in met een persoonlijk API-token: de assistent kan precies wat de scopes van het token en jouw rol toestaan, op de servers waar je toegang toe hebt. Via de MCP-server kan niets worden verwijderd.

Een assistent koppelen

Recepten

Opgeslagen bash-scripts voor elke server

Een recept is een bash-script dat je één keer schrijft en op een of meer actieve servers draait, als root of als de servergebruiker. Elke server krijgt zijn eigen taak, zodat je elke uitvoer apart volgt, en je kunt één e-mailrapport krijgen als alles klaar is.

Variabelen zoals {{server_name}}, {{ip_address}}, {{private_ip_address}} en {{server_type}} worden per server ingevuld vlak voordat het script draait.

Recept: schijfruimte opruimen

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

Deploy-hooks

Laat je eigen systemen weten wanneer er gedeployd is

Zet de Deploy-hook van een site aan en Vimonto Deploy stuurt na elke deploy, geslaagd of mislukt, een POST met JSON naar je HTTPS-endpoint, zonder de deploy op te houden. Gebruik het voor een chatbot, een changelog of een automatiseringstool, en controleer het met Deploy-hook testen.

Liever e-mail? Voeg tot 10 adressen toe, ook buiten de organisatie, die een e-mail krijgen zodra een deploy van de site mislukt.

Payload van de deploy-hook (ingekort)

{
    "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"
    }
}

Vragen over automatisering

Gebruik ik de deploy-URL, de CLI of de API?

De deploy-URL is het eenvoudigst: één curl -X POST, zonder token, maar je pipeline weet dan niet of de deploy is gelukt. De CLI met --watch wacht en laat de job falen bij een mislukte deploy. De API geeft je hetzelfde in je eigen scripts.

Kan ik via de API servers of sites aanmaken?

Nog niet. De API leest servers, sites, deployments, databases, back-ups, recepten en taken; start deploys; maakt en verwijdert databases; en draait back-ups en recepten.

Wat heeft de CLI nodig?

PHP 8.2 of nieuwer met de curl-extensie, en een API-token. Hij draait op macOS, Linux en WSL en heeft geen SSH-toegang tot je servers nodig: hij praat alleen via HTTPS met de API.

Waarom krijgt mijn pipeline een 409?

Er draaide al een deploy van de site, vaak omdat push to deploy er een startte. Zet Deployen bij elke push uit voor sites die CI deployt.

Wie mag recepten draaien?

Eigenaren, beheerders, managers en developers. Leden die beperkt zijn tot hun teams kunnen alleen recepten draaien op hun eigen servers. Zie beveiliging en teams.

Je volgende deploy kan live zijn voordat je koffie koud is.

Maak een organisatie aan, koppel een server en push. Meer is het niet.