The three charm paths

Not all workloads are the same. Cantrip recognises three distinct categories and uses a different approach for each.

Why three paths?

A Flask web application and a PostgreSQL cluster have fundamentally different operational requirements. A Flask app needs a container, an ingress, and maybe a database relation. PostgreSQL needs replication, failover, backup, point-in-time recovery, and careful upgrade management.

Treating them the same would mean either over-engineering simple applications or under-engineering complex ones. Cantrip addresses this by selecting a charm path during the research phase, before any code is written.

Path A: 12-factor PaaS applications

Path A is for stateless web applications that follow the twelve-factor methodology: Flask, Django, FastAPI, Go HTTP servers, Express, Spring Boot.

These applications share a common pattern: they are containerised, configured via environment variables, and fronted by a reverse proxy. Canonical's paas-charm base handles all of this with minimal custom code.

Path A is fast. The agent generates a rockcraft.yaml to build the OCI image, configures the paas-charm base, wires up ingress and COS, and deploys. For a simple application, this takes under two minutes from description to active/idle.

What you get

OCI image via Rockcraft
paas-charm base with framework-specific configuration
Ingress integration
COS integration (traces, metrics)
Config options mapped from environment variables

Path B: Custom applications

Path B handles applications that do not fit the 12-factor model but are not infrastructure software either. Examples include legacy monoliths, applications with custom lifecycle management, or workloads with unusual deployment requirements.

The agent scaffolds a full charm from scratch using the ops framework, analyses the application's requirements, and generates custom event handlers for install, config-changed, start, stop, and any relations the application needs.

What you get

Full ops framework charm with custom handlers
Application-specific config options and actions
Relations tailored to the application's needs
COS integration
Unit and integration tests

Path C: Infrastructure software

Path C is for databases, message queues, caches, and other stateful infrastructure. These workloads have complex operational requirements: clustering, replication, leader election, failover, backup and restore, scaling, and upgrade strategies.

Before writing any code, the agent checks Charmhub for existing charms. If a production-quality charm already exists, the agent recommends using it instead of building a new one. When a new charm is warranted, the agent researches the software's operational patterns in depth and proposes a comprehensive design covering day-2 operations.

What you get

Full ops framework charm with operational complexity
Clustering and replication support
Backup and restore actions
Scaling policies
Upgrade and rollback procedures
Comprehensive COS integration
Extensive testing (unit, integration, chaos, scaling, upgrade)

How the agent chooses

Path selection happens during the research phase. The agent:

Searches the web for information about the workload.
Uses the analyse_framework tool to detect the application type if source code is available.
Checks Charmhub for existing charms.
Evaluates the workload against path criteria: Does it follow 12-factor patterns? Is it stateful infrastructure? Does it need custom operational logic?

The selected path is included in the design proposal. You can override the choice — for example, telling the agent to use Path B instead of Path A if you need more control over the charm's event handlers.