canner db | Liste les bases de données d'un projet, ou en initialise/ajoute une. Le forfait Démarrage a une base par projet; les forfaits payants peuvent en ajouter. `db init --dedicated [--pitr-days N]` crée la base principale sur sa propre instance dédiée avec récupération à un instant précis; si le projet n'a aucune unité d'instance dédiée, une est ajoutée (9 $/mois), donc la commande affiche le prix et exige `--yes`. |
canner db export / import | Télécharge un pg_dump d'une base (tous les forfaits), ou en restaure un dans une base (tous les forfaits). |
canner db migrate-in / migrate-out / copy | Transfère une base depuis (ou vers) n'importe quel serveur Postgres public, ou copie une base Canner dans une autre (la copie exige un forfait payant). |
canner db rm / pg-version / ops | Supprime une base supplémentaire, la déplace vers une autre version de Postgres, ou vérifie une opération en cours. |
canner db external / rotate | Active/désactive l'accès externe avec une liste d'adresses autorisées, ou fait pivoter le mot de passe d'une base. Tous les forfaits. |
canner db backup-policy / backup / backups | Définit l'intervalle et la conservation des sauvegardes planifiées d'une base, lance une sauvegarde manuelle, ou liste/télécharge/restaure/supprime des sauvegardes. Démarrage : au plus une sauvegarde par jour, et restauration sur place plutôt que dans une nouvelle base. |
canner db diff / inspect / backups --verify / alerts | Restaure dans une base temporaire à examiner et la compare à la base actuelle, la conserve ou la prolonge, teste la restauration d'une sauvegarde et gère les alertes par courriel/webhook. Tous les forfaits. |
canner db resources | Affiche et modifie le budget de mémoire que votre application partage avec son instance dédiée, et l'applique (redémarre brièvement l'instance). Tous les forfaits. |
canner db extensions / tuning / restart | Installe pgvector, PostGIS, pg_trgm, pg_cron et d'autres extensions sur l'instance dédiée; choisit un préréglage de charge, des délais d'expiration et une fenêtre de maintenance; redémarre l'instance tout de suite. Option payante. |
canner db replication | Active la réplication logique (redémarre l'instance), crée des publications, surveille les slots de réplication et leur limite de WAL, et donne un accès de réplication à un destinataire avec `canner db roles <nom> create <n> --replication`. Option payante. |
canner db subscriptions | Suit en direct un serveur Postgres externe : ajoute un abonnement à partir d'une URL de connexion (lue depuis une variable d'environnement ou l'entrée standard, jamais affichée) et de noms de publications, puis l'actualise, le suspend, le reprend ou le retire. Les changements sont appliqués avec les droits du propriétaire de vos tables. Option payante. |
canner db metrics / monitoring / insights / logs | Métriques d'une base et, sur l'instance dédiée : active les requêtes lentes et les journaux (redémarre brièvement l'instance), liste les requêtes les plus lentes et lit le journal Postgres. Tous les forfaits. |
canner db roles / offsite | Crée des rôles en lecture seule ou en lecture et écriture avec leurs propres chaînes de connexion, et gère jusqu'à cinq destinations hors site compatibles S3 (ajout, modification, test, retrait) qui reçoivent des copies de vos sauvegardes. Le registre de migrations d'un rôle en lecture et écriture (schema_migrations et similaires) reste en lecture seule automatiquement; `canner db roles <nom> write-exclusions <rôle> <table>` protège toute autre table de la même façon, en direct, sans nouvelle chaîne de connexion. Tous les forfaits. |
canner db roles (groups, logins, audit) / inject | Appliquez votre propre modèle de privilèges sur l'instance dédiée. Créez un groupe (un rôle avec lequel personne ne se connecte, nommé par vous, auquel vos migrations accordent des privilèges et rattachent des politiques de sécurité au niveau des lignes; `--adopt` reprend un rôle NOLOGIN existant portant ce nom) et une connexion membre de vos groupes qui ne détient rien d'autre, sans accès général en lecture. `canner db roles <nom> member-of` modifie les groupes d'une connexion en direct, `canner db inject <nom> <connexion>` choisit la connexion que l'application reçoit comme DATABASE_URL (le propriétaire par défaut; s'applique dès le prochain déploiement), et `canner db roles <nom> audit` indique ce que chaque rôle peut réellement faire (tables, sécurité au niveau des lignes, politiques) et ce qui semble anormal; `--strict` fait échouer une exécution CI au moindre avertissement. Il n'est pas encore possible de déplacer une base ou de changer sa version de Postgres tant qu'elle comporte des groupes ou des connexions. Tous les forfaits. |
canner db check | Une vérification en lecture seule de la sécurité et de la performance de n'importe quelle base de données, sur tous les forfaits. Elle lit le catalogue (jamais vos données) et énumère : les politiques de sécurité au niveau des lignes qui autorisent toutes les lignes, plusieurs politiques permissives combinées par OU, les fonctions que tout le monde peut exécuter avec les droits de leur propriétaire (SECURITY DEFINER) ou sans search_path fixe, les vues qui contournent la sécurité au niveau des lignes, les schémas où tous les rôles peuvent créer des objets, les tables sans clé primaire, les clés étrangères sans index, les index en double et les tables dont l'autovacuum est désactivé. Sur une instance dédiée, elle rapporte aussi les rôles : l'application qui se connecte avec le propriétaire, l'accès général en lecture et un registre de migrations modifiable. `--category security|performance` filtre, `--strict` termine avec le code 1 au moindre avertissement (pour l'IC) et `--json` affiche tout le résultat. La même vérification est offerte dans le tableau de bord, sur chaque base de données. |
canner db least-privilege | Exécute l'application avec un rôle limité en une étape (instance dédiée). Crée un rôle en lecture-écriture (`--label` pour le nommer, `app` par défaut) qui peut tout lire et écrire les données mais pas modifier le schéma, garde en lecture seule tout registre de migrations connu (Prisma, Rails, Django, Flyway et autres), même celui que crée votre première migration, et l'injecte comme `DATABASE_URL`. Le propriétaire, qui peut modifier le schéma, est fourni à la commande de mise en production seulement sous `DATABASE_URL_MIGRATE` (jamais au build ni à l'application en marche) : lancez-y vos migrations. Peut être relancée sans risque. S'applique dès le prochain déploiement. `canner db roles audit` montre le résultat. |
canner db instance upgrade | Met à niveau une instance dédiée vers une version majeure de Postgres plus récente, sur place. `canner db instance upgrade` indique ce qui l'en empêcherait; `upgrade run --yes` l'effectue (`--pg 18` précise la version). Les bases de données, rôles, privilèges, politiques et extensions sont tous conservés et les chaînes de connexion ne changent pas : rien de ce que vous avez créé avec votre propre SQL n'est à refaire. Toutes les bases de l'instance sont hors ligne quelques minutes; si la mise à niveau échoue, l'instance reste telle qu'elle était. La récupération à un instant précis repart ensuite d'une nouvelle fenêtre. La version précédente est conservée 7 jours : `upgrade rollback --yes` y revient (et perd ce qui a été écrit depuis), `upgrade finish --yes` l'abandonne. |
canner db instance / pitr / pitr-restore / move | Crée une instance Postgres dédiée, gère la récupération à un instant précis, récupère une base à un moment donné dans une nouvelle base, copie l'archive de récupération hors site (`canner db pitr --offsite <destination>`), ou déplace une base vers/depuis l'instance. Option payante. |