Available Versions

Created: March 9, 2026 Updated: May 19, 2026

This document provides an overview of the currently available versions for our Blueprints and various programming languages and SDKs. It also captures the latest Flutter mobile template field notes from OMX activity and explains how the template works with the Tronador DevOps accelerator.

Blueprint & Language Versions

The following table summarizes the supported versions across different Blueprints:

Latest Blueprint Highlights

• Java, NodeJS, Python, .NET, and Docker received template hygiene updates around library environment inputs, metadata, and AI-agent working directories.
• Xcode and Android SDK received GitVersion preset and README template improvements that align them with the newer template families.
• Go added cloud-provider environment variables to deployment job definitions, reducing custom per-repository workflow edits.
• Rust updated GoReleaser GPG secrets guidance and release workflow behavior.
• Flutter Mobile moved from the early v1.0.0 template to v1.0.12, with a full Flutter-native build, artifact, iOS fallback, deployment, README, and GitVersion story.
• Shared cloudopsworks/blueprints support for Flutter mobile was validated through the v5.10 channel, with the latest observed Flutter-related blueprint release at v5.10.39.

Current Open Source Repository Rotation

Terraform Modules

The current public module rotation keeps at least six actively maintained Terraform modules visible and favors recently updated repositories:

• terraform-module-mongoatlas-aws-users — MongoDB Atlas users with AWS Secrets Manager and Lambda rotation dependencies.
• terraform-module-mongoatlas-users — MongoDB Atlas user management.
• terraform-module-aws-secrets-rotation-lambda-setup — AWS Secrets Manager rotation Lambda setup aligned to database management modules.
• terraform-module-aws-alb-certificate-management — Application Load Balancer certificate management.
• terraform-module-gcp-cloud-storage — GCP Cloud Storage buckets with versioning, lifecycle, encryption, logging, and IAM policies.
• terraform-module-github-org-management — GitHub organization management.
• terraform-module-gcp-mysql-management — GCP Cloud SQL MySQL databases and users with Secret Manager credential storage.
• terraform-module-aws-mysql-management — AWS MySQL and MariaDB database/user management with Secrets Manager and Hoop.dev integration.

GitHub Actions

Archived actions have been removed from the active list. The maintained action rotation keeps no fewer than three entries:

• changelog-action — maintained conventional commit changelog action.
• actions-runner — specialized GitHub Actions runner for Cloud Ops Works Blueprint pipelines.
• github-action-jira-release — creates Jira releases that synchronize with GitHub releases.
• github-action-next-semvers — outputs next major, minor, and patch versions from a semver input.

Important Notes

• Recommendation: Prefer the newest template releases listed above when creating or upgrading repositories. The newer versions include GitVersion preset alignment, documentation updates, CI/CD path fixes, and safer agent-runtime ignore rules.
• Breaking Changes: Blueprint v5.10 includes an important API Gateway deployment change. Coordinate migrations before upgrading older API Gateway deployments.
• GitHub Repo Management: Version v1.3.1 of terraform-module-github-repo-management adds support for creating newer language families including Go, .NET, and Rust.
• Flutter Mobile: Use the v5.10 blueprint channel with fluttermobile-app-template v1.0.12 or newer so Flutter fixes can be consumed without pinning every workflow to a patch-specific blueprint tag.
• Upgrading: When upgrading older generated repositories, include the original Blueprint version used to create them to avoid accidental drift.

Upgrade Commands

Use the following commands to manage your version upgrades:

• make repos/upgrade: Continues to work the same way, but upgrades patch versions.
• make repos/upgrade/major: Used to jump to the latest major version.
• make repos/upgrade/vX.Y.Z: Used to upgrade to a specific version, recommended when a repository is older than the currently supported baseline.

Flutter Mobile Template Usage Reference

1. Create a repository from cloudopsworks/fluttermobile-app-template.
2. Keep .cloudopsworks/.fluttermobile as the repository marker so checkout and upgrade tooling can recognize the template family.
3. Configure .cloudopsworks/vars/inputs-global.yaml as the source of truth for Flutter channel/version, target file, platform matrix, Android artifact types, iOS scheme, Xcode version, signing, and deployable artifact type.
4. Keep workflow references on the cloudopsworks/blueprints v5.10 channel unless testing a specific patch release.
5. Add environment files such as inputs-dev.yaml, inputs-uat.yaml, and inputs-prod.yaml before enabling deployment.
6. Use Tronador GitFlow targets for branch creation, version file generation, release branches, tags, and publish automation so mobile repositories follow the same lifecycle as the rest of the CloudOpsWorks catalog.
7. Validate with the sample app pattern: quality, Android build, iOS build, artifact upload, mobile deploy, and scans should all pass before promoting a release.

Benefits with Tronador DevOps Accelerator

• Consistent lifecycle: Tronador provides the GitFlow, version, tag, and release mechanics while the template provides mobile-specific defaults.
• Reusable fixes: Flutter build, artifact, signing, and deploy behavior lives in cloudopsworks/blueprints, so fixes can be released once and consumed through the v5.10 channel.
• Lower workflow drift: Teams configure inputs-global.yaml instead of copying large workflow bodies across repositories.
• Cross-platform readiness: Android-only, iOS-only, and combined mobile pipelines can be controlled from the matrix without forking the template.
• Safer staging: GitFlow release branches and environment files let teams validate staging behavior before production promotion.
• Operational evidence: The template was validated through a sample repository with successful quality, build, deploy, and scan jobs after the blueprint fixes.

Field Story: Building the Flutter Mobile Template with OMX and Tronador

On May 18 and May 19, 2026, the Flutter mobile template moved from a promising scaffold into a release-backed delivery template. The work started with a simple architectural problem: a Flutter application is not only an Android application and not only an Xcode application. It contains Gradle and Xcode projects, but the build contract is the Flutter toolchain, the output paths are Flutter output paths, and the maintenance burden belongs in reusable blueprints rather than duplicated workflow steps. The OMX activity around ../fluttermobile-app-template captured that realization early. The first plan rejected shortcuts that would have copied Android SDK and Xcode behavior into the template. It chose a Flutter-native build layer, with CloudOpsWorks checkout, GitFlow environment mapping, artifact publishing, release management, scans, and mobile deployment still handled through the established Tronador and Blueprint conventions.

That distinction mattered because the repository looked deceptively close to the native templates. The Android wrapper lived under android/, not at the repository root. The iOS project existed under ios/, but the reliable release command was still flutter build ipa, not a hand-written xcodebuild invocation. The previous workflow shape was inherited from the Android SDK template and referenced Android matrix outputs that were never emitted for Flutter. The planning notes called out a concrete break in the PR workflow: an android_schemes output was referenced even though the Android config blueprint did not produce it. In a native Android repository that mismatch might have hidden behind a narrower matrix; in Flutter it would block the template from proving the core promise of one repository producing mobile artifacts for both platforms.

The OMX memory also records an important governance choice. Reusable action behavior belongs in cloudopsworks/blueprints; template defaults belong in cloudopsworks/fluttermobile-app-template; sample validation belongs in cloudopsworks/fluttermobile-app-sample. That boundary prevented the template from becoming a one-off automation snowflake. Instead of burying platform knowledge in inline workflow steps, the work pushed Flutter knowledge into reusable blueprint actions, kept the template as an orchestrator, and used the sample repository as an integration test target. This is the point where Tronador becomes more than a Makefile include. Tronador gives the repositories a common GitFlow, version, branch, and release vocabulary, while the blueprints give the workflows reusable behavior. The Flutter template becomes a productized entry point into that operating model.

The first visible failures came from the sample repository. The checkout phase did not recognize the Flutter marker file and attempted to resolve a module URL without a repository owner, effectively building https://github.com/.git. The failing sample runs, recorded as 26111084435 and 26111084436, showed that the checkout module-version check had been written for existing technology markers and did not yet understand .cloudopsworks/.flutter or .cloudopsworks/.fluttermobile. The fix became blueprint release v5.10.33: marker compatibility for Flutter mobile in cd/checkout/check-module-version, with a safer exit path when no marker is present. That small correction was foundational. Before a mobile app can build, the platform has to know what kind of repository it is checking out.

After checkout was corrected, the work shifted to Flutter build reality. MacOS runners still have Bash 3 in common contexts, and Bash 3 does not behave like newer Bash when empty arrays are expanded. That detail created a portability problem for the Flutter build action. Artifact upload introduced another issue: actions/upload-artifact@v7 rejected normalized paths that included source/./.... These were not product feature bugs; they were the kind of CI sharp edges that only appear when the template is exercised end-to-end. Blueprint release v5.10.34 addressed the build and artifact path compatibility so that the template could pass artifacts across jobs without depending on fragile path forms.

The iOS lane then forced the next set of decisions. Flutter can build an iOS app, but the shape of a deployable IPA depends on signing, archive export, workspace availability, and provisioning metadata. The template had to support practical defaults while still leaving a path for real signed deployment. Blueprint release v5.10.35 added signed iOS IPA fallback behavior. Release v5.10.36 made archive export explicit. Release v5.10.37 handled the common case where a default Flutter app has an Xcode project but no ios/Runner.xcworkspace. Release v5.10.38 added a manual provisioning fallback by decoding mobile provisioning metadata. In story form, that sequence is the journey from “Flutter can make iOS output” to “a platform team can explain what happened when signing is missing, when CocoaPods has not created a workspace, or when the runner needs export metadata.”

Deployment exposed a different mismatch. Build jobs uploaded artifacts with Flutter’s directory structure preserved. The mobile deploy actions expected APK or IPA files at the artifact root. That is a classic integration-contract bug: every component is doing something reasonable, but the boundary between them is underspecified. Blueprint release v5.10.39 made mobile deploy actions search recursively for nested mobile artifacts, which let AWS Device Farm and Google Firebase Test Lab deployments consume the outputs produced by the Flutter build lane. The final sample Release Build after the template upgrade passed at run 26119028000, including Preload, Flutter Quality, Android build, iOS build, Android deploy, iOS deploy, and SAST/SCA scan jobs. Process OWNERS also passed at run 26119027848. Those results are important because they verify the template as an operating system for delivery, not just as a skeleton project.

The template releases tell the same story in smaller increments. Version v1.0.7 pinned the template to the project archive fallback. Version v1.0.8 pinned the manual provisioning fallback. Version v1.0.9 pinned the nested mobile deploy artifact fix. Version v1.0.10 moved workflow references to the v5.10 minor channel instead of patch-specific blueprint tags. That last move is operationally significant: teams consume a maintained channel and receive compatible patch improvements without editing every repository for every blueprint patch. Version v1.0.11 added a detailed README-TEMPLATE.yaml, and version v1.0.12 converted the template guide to Markdown, added GitVersion configuration presets, and cleaned ignore rules. The current public release is therefore not a single big bang; it is a sequence of small releases that turned evidence from failing runs into reusable behavior.

From a user perspective, the Flutter mobile template is now a practical starting point for a cross-platform mobile repository. A team begins with the template, keeps the .cloudopsworks/.fluttermobile marker, configures .cloudopsworks/vars/inputs-global.yaml, and lets the Flutter matrix choose Android, iOS, or both. The Android side can emit APK or AAB outputs depending on the intended delivery path. The iOS side can run unsigned smoke builds or signed IPA flows when certificates and provisioning information are present. Quality jobs run Flutter dependency resolution, analysis, and tests before release or deployment jobs consume artifacts. The default posture is intentionally safe: mobile preview deployment is disabled until the environment inputs and credentials are ready.

A typical usage path is straightforward. Create a new repository from cloudopsworks/fluttermobile-app-template. Run the standard Tronador initialization for the repository so package metadata, GitVersion, labels, and repository settings align with the organization. Keep workflow references on cloudopsworks/blueprints/cd/checkout@v5.10 and pass blueprint_ref: v5.10 unless a specific test requires a patch tag. Edit the Flutter configuration in inputs-global.yaml: choose the Flutter channel or version, set the target file if it is not lib/main.dart, enable Android and iOS as needed, choose Android artifact types, and set the iOS scheme, SDK, destination, export method, and signing mode. Add environment-specific files such as inputs-dev.yaml, inputs-uat.yaml, and inputs-prod.yaml when deployment is needed. Then work normally through GitFlow: feature branches for template changes, release branches for staging validation, and master or main promotion for production release.

The benefits of using this template with the Tronador DevOps accelerator are strongest at the boundaries where teams usually lose time. First, repository creation is standardized. A new mobile app does not need to rediscover branch protection, release labels, version files, CI workflow structure, or environment file naming. Second, release semantics are consistent. Conventional commits and +semver: annotations feed GitVersion, while Tronador targets keep the branch and version workflow predictable. Third, platform differences are isolated. Android, iOS, AWS Device Farm, and Firebase Test Lab behavior stays in reusable blueprints where fixes can be released once and consumed by many repositories. Fourth, the template stays inspectable. Teams can read inputs-global.yaml and understand what matrix rows will run without spelunking through hundreds of workflow lines. Fifth, sample-backed validation reduces template risk. The sample app is not decoration; it is the proof that the template can build, publish artifacts, deploy to mobile test services, and pass scans.

The OMX activity also surfaces a lesson about compatibility markers. During the sample upgrade, current Tronador make repos/upgrade did not directly recognize .cloudopsworks/.fluttermobile. The team used the existing Android template detection path with ANDROIDSDK_TEMPLATE=cloudopsworks/fluttermobile-app-template, then removed the temporary .cloudopsworks/.android marker before the final commit. That workaround kept the release moving, but it also identified a future improvement: add native .fluttermobile support to Tronador repository initialization and upgrade flows. In practical terms, the template already works; the accelerator can become even smoother by understanding Flutter as its own first-class repository family.

For engineering leaders, the value is governance without a productivity tax. The template does not ask every team to become a mobile CI specialist. It gives them a known path for Flutter quality checks, Android builds, iOS builds, artifact collection, release creation, mobile test-lab deployment, and scanning. It also gives platform engineers a central place to improve behavior. When a runner path changes, when an artifact action changes rules, or when iOS signing needs a safer fallback, the fix lands in blueprints and rolls through the v5.10 channel. Tronador provides the operational rhythm around that channel: initialize, upgrade, version, release, and promote.

For developers, the value is less waiting and less guesswork. A branch can prove Android and iOS behavior in one pipeline. A missing provisioning profile fails with a clearer reason. A deploy job can find a nested APK or IPA instead of assuming every artifact is at the root. A release branch can move to staging with the same conventions used by the rest of the CloudOpsWorks catalog. The template also keeps the door open for teams that only need Android at first. They can remove iOS from the matrix, control PR cost, and later re-enable iOS without changing the entire workflow model.

The result is a mobile blueprint that reflects how delivery actually evolves. It started with copied native assumptions, hit checkout and artifact failures, discovered iOS signing edge cases, released reusable fixes, validated them in a sample app, and documented the path for future users. OMX provided the activity memory and the structured planning discipline; Tronador provided the release mechanics and repository lifecycle; the blueprints provided reusable CI/CD behavior. Together they turned a Flutter sample into a maintained CloudOpsWorks template that teams can use for real mobile delivery.

Operational Playbook from the Session

The operational playbook that emerged from the session is intentionally conservative. Start with the repository marker, because the marker tells checkout, upgrade, and module-version tooling which family of conventions applies. Keep .cloudopsworks/.fluttermobile in the repository and avoid pretending that the project is merely Android or merely Xcode. Next, keep all workflow references pointed at the v5.10 blueprint channel. The field work showed why a channel is better than a patch pin for ordinary template users: several fixes were released in quick succession, and a patch-pinned repository would have needed repetitive workflow edits just to consume compatibility fixes. A channel lets the central blueprint release train carry safe patch improvements forward while the template remains stable.

Then configure the matrix before enabling deployment. Android-only repositories can begin with Android rows and add iOS later. iOS-heavy teams can enable the macOS lane and provide signing material once they are ready for deployable IPA output. Teams that only need smoke confidence can keep unsigned behavior for early validation. This staged posture is one of the key benefits of a template over a hand-built workflow. It lets a team adopt the shape of the platform without activating every expensive or credential-heavy lane on day one. The template does not make mobile delivery magically free; it makes the costs explicit and movable.

The session also established a useful validation ladder. First validate YAML and repository shape. Then compare template and sample workflow files to make sure the sample is actually consuming what the template publishes. Then run the sample Release Build and inspect every job family: preload, Flutter quality, Android build, iOS build, mobile deploy, and scans. Finally check repository process automation such as OWNERS. This ladder is valuable because it catches different classes of error. Static validation catches syntax and schema mistakes. Diff validation catches documentation or sample drift. Sample workflow runs catch real runner behavior. Process checks catch governance issues that would otherwise appear only when a team tries to merge or release.

Why the Story Matters for Template Users

The Flutter mobile template story matters because most organizations underestimate the distance between a green local Flutter build and an operational mobile delivery system. A developer can run flutter build apk or flutter build ipa locally and still not have artifact retention, release assets, cloud test-lab deployment, semver release notes, branch protection, scanning, or repeatable environment promotion. The template closes that gap by encoding the path that was proven during the OMX session. It does not replace Flutter knowledge; it surrounds Flutter with the DevOps contracts that a production team needs.

The template also reduces handoff friction between application teams and platform teams. Application developers care about targets, schemes, signing mode, artifact type, and whether the build passed. Platform teams care about branch models, version channels, secrets, runner compatibility, release governance, and reusable action ownership. By putting application choices in inputs-global.yaml and reusable behavior in blueprints, both groups get a clean interface. The developer changes configuration instead of editing workflow internals. The platform team improves an action once instead of opening pull requests against every mobile app.

That separation is exactly where Tronador fits. Tronador is the accelerator that keeps repository lifecycle operations boring: initialize, align metadata, create the right branch shape, calculate versions, generate version files, tag, publish, and promote. The Flutter template plugs mobile-specific behavior into that lifecycle. When a team asks for staging, the answer is not a one-off script; it is a GitFlow release path with the same semantics used elsewhere in the CloudOpsWorks portfolio. When a team asks how to upgrade, the answer is not “copy these workflow snippets”; it is “consume the template and blueprint channel through the established upgrade flow.”

The session closed with a healthy backlog item rather than a hidden defect. Native .fluttermobile support should be added to Tronador repository upgrade detection so future upgrades do not need the temporary Android compatibility marker workaround. That is a sign of a maturing template family. The immediate template works, the sample proves it, and the remaining improvement belongs in the accelerator so the next user has a smoother first experience. In other words, the work did not merely patch a workflow. It created feedback for the platform itself.

Practical Benefits Recap

For a delivery manager, the practical benefit is predictability. A new Flutter repository starts with known defaults and a documented release path. For a security reviewer, the benefit is consistency: scans and artifact handling are part of the same blueprint-driven model as other templates. For a mobile engineer, the benefit is faster platform enablement: Android and iOS outputs can be activated through matrix configuration, and the common failure modes around nested artifacts, missing workspaces, archive export, and provisioning metadata have already been handled. For a platform maintainer, the benefit is leverage: improvements to blueprints flow to all consumers on the channel.

The story from OMX memory is therefore a field report about reducing entropy. Every failed sample run produced a sharper contract. Every release made one part of the platform more reusable. Every template update moved a choice from tribal knowledge into versioned configuration or documentation. Used together, fluttermobile-app-template and the Tronador DevOps accelerator give CloudOpsWorks users a repeatable mobile delivery starting point: not only a Flutter app scaffold, but a governed path from repository creation to staging validation and production-ready release.