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.

What is a module?

A module is an independent microservice that:

• Runs as its own Docker container alongside the core services
• Has its own Docker image published to the Codeberg Container Registry
• Connects to the shared PostgreSQL database, scoped to its own data using a provider field
• Runs scheduled scans automatically (e.g. every night at 3 AM) and stores findings in the database
• Exposes a REST API that the backend queries to surface data in the Strawly UI
• Can be toggled on or off at any time without affecting other services

Available modules

Module	Cloud provider	What it does
Azure Optimizations	Microsoft Azure	Scans for rightsizing and termination opportunities using Azure Cost Management and Azure Advisor

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

How modules appear in the UI

When a module is enabled and running, it registers itself in Strawly's module registry. The frontend reads this registry and automatically shows the module's section in the sidebar navigation. If you disable a module, its section disappears from the UI on the next page load.

Enabling and disabling modules

Modules are managed in strawly-deployment.yml. See Module Management for step-by-step instructions.

How module data works

All modules write to shared database tables and use a provider field to keep their data separate. For example, the Azure Optimizations module writes opportunities with provider: 'azure'. This means:

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

Building a new module

If you want to extend Strawly with a new cloud provider or optimisation category, see the Building Modules guide.