Architecture

The Serverless Maven Plugin is a multi-module Maven project. A thin set of Maven Mojos drives a five-phase lifecycle (validate → plan → deploy → verify → undeploy) over a shared, immutable domain model. Each phase is implemented by a dedicated library module, and a cloud-provider strategy abstracts the actual AWS / Azure / GCP calls behind a single interface.

This section documents how the plugin is structured internally — the modules and how they depend on one another, the end-to-end deploy pipeline, and the cross-cutting concerns (state, credentials, multi-cloud). For how to use the plugin, see the Getting Started and Configuration Reference pages.

In This Section

Structure

Modules & Dependencies

The eleven Maven modules, their responsibilities, and the dependency graph that fixes the build order.

Runtime

Deploy Pipeline

The end-to-end data flow from config JSON to deployed cloud resources, hop by hop.

Cross-cutting

State, Credentials & Multi-Cloud

The state manifest and locking, the credentials abstraction, the provider strategy pattern, and verify/undeploy.

The Big Picture

A single mvn serverless:deploy invocation flows top to bottom through the layers below. The Maven layer orchestrates; the phase libraries do the work; the domain model is the common currency passed between them.

High-level layered architecture
Layered view. All three provider strategies (AWS, Azure, GCP) have real per-component deployers; a handful of resources still record the resource pending stable-SDK wiring (see the multi-cloud page).

Key Design Ideas

  • Sealed domain model. Every component is a record implementing the sealed Component interface, so parsing, validation, planning, deployment, and teardown all pattern-match over the same closed set of types.
  • Phase cascade. Running any goal automatically runs the phases it depends on first (deploy runs validate then plan), halting the build on the first failure.
  • Declarative diffing. The planner compares desired configuration against live cloud state (and a persisted state manifest) to compute a change plan of create / update / delete / unchanged.
  • Derived least-privilege permissions. Links between components are translated into narrowly-scoped IAM/RBAC grants — wildcards are rejected.
  • Provider strategy. A single CloudProviderStrategy.deploy(...) entry point hides all provider-specific SDK work behind the sealed component model.

Continue with Modules & Dependencies →