Canner a commencé par la chose la plus simple : déposez un projet, obtenez une URL en direct. Une plateforme de déploiement qui ne nécessitait même pas de compte. Mais une fois un projet en ligne — Canner y compris — on a souvent besoin de faire plus que juste l'héberger. Redéployer, lire les échecs, laisser un agent IA livrer des correctifs, et simplement le cycle de développement normal qui suit tout lancement de MVP. Il y a toute une surface documentée pour ce qu'on ouvre à vos agents, et elle a beaucoup grandi depuis la première publication de ce billet. Alors, où en est-on aujourd'hui?
Une API REST documentée
Tout ce que fait le tableau de bord, votre propre code peut maintenant le faire aussi : créer et configurer des projets, lancer des déploiements, lire les métriques et les journaux, gérer les variables d'environnement, relier et configurer des domaines, et maintenant une surface Postgres véritablement profonde — sauvegardes, récupération à un instant précis, rôles, extensions. La page développeurs liste 8 groupes de ressources et 45 opérations; la ressource base de données à elle seule compte plus de 80 points de terminaison. Tout ça vit sous /v1. Ça mériterait peut-être un incrément. Il y a une référence interactive appuyée sur la spécification OpenAPI 3.1. Authentifiez-vous avec un jeton bearer (cnr_…) et attendez-vous à des formes d'erreur cohérentes avec un request_id, des en-têtes de limite de débit, et une pagination par curseur sur les points de terminaison de liste.
curl https://api.canner.ca/v1/projects \
-H "Authorization: Bearer cnr_votre_jeton_ici"Une CLI qui parle JSON
@canner-ca/cli couvre beaucoup plus que « déployer le répertoire courant » maintenant : login, projects, init, status, open, deploy, redeploy, logs, token, env, domains, et une famille canner db pour import/export/migrate-in/migrate-out/copy sur Postgres. Ajoutez --jsonà presque n'importe quelle commande pour obtenir un objet lisible par machine au lieu d'un tableau formaté, prêt à passer dans jq ou à remettre à un programme.
canner projects --json | jq -r '.[].slug'
canner db export mon-site --out backup.dump
canner env set API_KEY=secret --sensitive
canner domains add www.exemple.comLa liste complète des commandes est sur la page CLI.
Serveur MCP pour les agents IA
@canner-ca/mcpest toujours à zéro dépendance et codé à la main — rien de plus à auditer — donc il est toujours sécuritaire par défaut : seules les lectures et les écritures sûres, aucun outil pour supprimer un projet ou révoquer un jeton sur lequel un agent pourrait trébucher ou vouloir « tester ». Mais ce n'est plus onze outils, c'est plus de trente, avec une lourde couverture Postgres en plus des outils originaux de projet et de domaine. Il y a aussi une deuxième option maintenant : un serveur MCP distant à api.canner.ca/mcp (Streamable HTTP) pour les bâtisseurs dans le navigateur comme Lovable, Bolt et v0, qui ne peuvent pas exécuter un processus npx local. La configuration du serveur local tient en un bloc et un jeton; la page MCP contient les extraits exacts.
Toujours canadien
L'API répond depuis la même infrastructure à Montréal qui sert vos projets — il n'y a aucun intermédiaire ni service tiers entre les deux. Tout est géré chez Canner, pas acheminé par l'infonuage de quelqu'un d'autre — tout le but, comme sur la page souveraineté, est que non.
Si vous bâtissez avec des agents, llms.txt décrit Canner pour les modèles de langage et la spécification OpenAPI est prête à devenir des définitions d’outils. Les deux sont publics — aucun compte requis pour les lire.