Modules Overview¶

Strawly uses a modules architecture — the core platform handles authentication, user management, and the shared database, while optional modules add cloud-specific functionality. You enable only the modules you need, and you can toggle them at any time without affecting the core services.

What is a module?¶

A module is an independent microservice that:

Runs as its own Docker container alongside the core services, from an image published to the Strawly container registry
Is toggled on or off in strawly-deployment.yml
Connects to the shared PostgreSQL database, writing to its own prefixed tables (az_*, aws_*, etc.)
Runs scheduled scans on a configurable schedule and accepts manual runs triggered from the UI
Exposes a REST API that the backend queries to surface data in the Strawly UI
Is registered in the module registry by the seed-modules script so the frontend can display it

Available modules¶

Module	Cloud provider	What it does	Port
Azure Optimizations	Microsoft Azure	Scans for upsizing, downsizing, and termination opportunities using Azure Monitor metrics and Azure Pricing	3002

More modules are in development. Watch the releases page for announcements.

How module data works¶

Each module writes to its own set of prefixed tables in the shared PostgreSQL database. Azure tables are prefixed az_, and future cloud-provider modules follow the same convention (aws_*, gcp_*). This means:

Multiple modules coexist in the same database without conflicting
Disabling a module does not delete its historical data
The core backend can query data from all modules through a single API

Enable a module¶

Open strawly-deployment.yml and set the module to enabled: true:
```
modules:
  optimizations-azure:
    enabled: true
```
Add the required credentials to .env (see Environment Variables for each module's variables).

Regenerate the compose file, redeploy, and refresh the module registry:

npm run generate-compose
docker compose -f docker-compose.generated.yml pull
docker compose -f docker-compose.generated.yml up -d
npm run seed-modules

Disable a module¶

Open strawly-deployment.yml and set the module to enabled: false:
```
modules:
  optimizations-azure:
    enabled: false
```

Regenerate and redeploy with --remove-orphans to stop and remove the module container, then refresh the registry:

npm run generate-compose
docker compose -f docker-compose.generated.yml up -d --remove-orphans
npm run seed-modules

The module's data in the database is not deleted when you disable a module. Re-enabling it later will continue from where it left off.

Change a module's scan schedule¶

Scan schedules are configured at runtime in the Strawly UI, not in strawly-deployment.yml. Open Settings > Modules, select the module, and set a schedule per scan type. No schedule is set by default; nothing runs automatically until you set one. The scheduler re-reads schedules within 60 seconds, so no redeploy is needed.

You can also trigger a scan immediately from Settings > Modules. Each scan type (inventory, metrics, recommendations, pricing) has its own schedule and its own Run now button. See Azure Optimizations for the full scan model.

Why the YAML toggle exists alongside the UI Settings toggle¶

There are two places you can influence whether a module is active: strawly-deployment.yml and the Module Settings page in the Strawly UI. They control different things.

Layer	What it controls	Who changes it
`strawly-deployment.yml`	Whether the container is scheduled and running	Sysadmin, at deploy time
Module Settings (UI)	Whether the module is visible and usable to users	Admin, at runtime

Setting a module to enabled: false in the YAML means generate-compose omits it from docker-compose.generated.yml entirely: the container is never started, no image is pulled, no RAM is allocated, no port is bound, and no health checks run. The seed-modules script also marks its registry entry disabled, so the frontend never shows it and the backend never issues permissions for it.

The UI toggle can hide a module from users, but it cannot stop a running container or reclaim the resources it holds.

For an operator running Strawly on AWS with no Azure footprint, always deploying the optimizations-azure container would pull a multi-hundred-megabyte image, consume 256 MB or more of RAM, and run a health-check loop continuously, for a service they have no credentials for and no use for. The YAML toggle eliminates that. As more cloud-provider modules are added, the difference compounds.

The practical rule: use strawly-deployment.yml to decide which modules your installation supports, and use the UI to control which of those modules your users can see.

Verify a module is running¶

# Check container status
docker compose -f docker-compose.generated.yml ps

# Check module health
curl http://localhost:3002/health

# View module logs
docker compose -f docker-compose.generated.yml logs -f optimizations-azure