Flamingock is an Apache-2.0 Java library that brings Change-as-Code to an application's stack, applying versioned, auditable changes to the external systems an application depends on — database schemas, message queues, event and API schemas, configuration values, and cloud resources — at startup and in lockstep with the code release, for Java and Kotlin teams that need system evolution to be governed rather than run from manual scripts.

What it is

Flamingock is an open-source project written in Java and distributed through Maven Central, consumed as a Gradle plugin with the identifier io.flamingock and configured through a community() step. It implements Change-as-Code (CaC): every change to an external system is defined as code, versioned, reviewable, executable, and auditable, then applied in a strict, deterministic order when the application starts, verified before traffic is served, and recorded in an external audit log. If Flamingock cannot guarantee a safe outcome, it stops rather than proceeding, which prevents silent corruption and partial execution. The project carries topics such as changelog, database-schema, schema-evolution, event-schema, and springboot, and its documentation lives at docs.flamingock.io.

The concrete problem it solves is the gap between an application's code and the things outside that code which the application depends on. Keeping a schema, a queue, a feature flag, or a configuration value in sync across environments typically means manual scripts, tribal knowledge, and hoping nothing breaks during a deploy. Flamingock replaces those out-of-band scripts and runbooks with an ordered, auditable execution tied to the application lifecycle, so a deployment behaves as a single consistent unit. It is explicitly not Infrastructure-as-Code: it does not provision servers, clusters, or networks, which the project assigns to tools such as Terraform and Pulumi, and instead covers the evolution layer that provisioning tools leave untouched.

Key capabilities

• Change-as-Code authoring: changes are defined as code in Java or Kotlin, or declaratively in YAML using official or custom templates, and remain versioned and reviewable.
• Unified system evolution: database schemas and reference data, message queues, topics and event schemas, APIs and configuration values, cloud resources tied to application behaviour, and feature flags, permissions and runtime policies are orchestrated as one ordered evolution.
• Startup-time synchronization: all required changes are applied when the application starts, so each environment is consistent before it serves traffic.
• Safety by default: the tool refuses to proceed when a safe outcome cannot be guaranteed, requiring manual intervention instead of allowing hidden corruption or partial execution.
• Audit logging: every execution is recorded externally with full traceability of what ran, when, by whom, and with what result.
• Coordinated multi-environment execution: change execution is managed safely across multiple environments and multiple application instances.
• Native GraalVM support: full compatibility with native image builds for fast startup and low memory usage.

Who uses it and how

• Java and Kotlin teams running Spring Boot services that want schema, queue, and configuration changes to ship as part of the release instead of as a separate migration step with its own runbook.
• Teams operating several environments and more than one application instance, who rely on coordinated execution so changes are applied once and consistently rather than raced by each instance.
• Organisations with audit and compliance obligations that need an external record showing what ran, when, by whom, and with what result for every environment.
• Platform teams that already provision infrastructure with Terraform or Pulumi and want an evolution layer for application-level systems without pushing application configuration into provisioning code.
• Existing Mongock users assessing the transition, since the project presents itself as Mongock's evolution for changes that extend beyond the database.

Getting started

Add the Gradle plugin id("io.flamingock") version "[VERSION]" and configure flamingock { community() }, replacing the placeholder with the latest version published on Maven Central. The project points to a Quick Start guide on docs.flamingock.io and to a separate examples repository for working setups.

How it compares

Among the tools named in the project's own material, Flamingock positions itself as the evolution of Mongock, aimed at teams that used Mongock for database change management and now need the same ordered, auditable model applied to queues, APIs, configurations, and cloud resources. It is framed as complementary to infrastructure-as-code tools such as Terraform and Pulumi rather than a competitor: those define where systems run, while Flamingock defines how they evolve.

When to use it — and when not to

A self-hoster takes on the operation of the external audit log Flamingock writes to and must ensure that the databases, brokers, and cloud services being changed are reachable at application startup, because execution is bound to the application lifecycle rather than to a standalone deployment job. It is the wrong choice for provisioning servers, clusters, or networks, and for teams that want infrastructure definition and system evolution handled by one tool. A fair limitation is that the README lists the categories of systems it manages but does not enumerate the individual integrations or their maturity, and it does not detail what the enterprise offering adds beyond the Apache-2.0 core, so integration-specific verification against the documentation is worthwhile before committing.

Coming from <a href="https://github.com/flamingock/mongock-legacy#%EF%B8%8F-mongock-is-deprecated">Mongock</a>?  
Learn about the transition and why Flamingock is its evolution.

plugins {
    id("io.flamingock") version "[VERSION]"
}

flamingock {
    community()
}