Conan, Ansible Galaxy, Terraform, Swift, and Emerging Repository Formats: Concepts, Architecture, and Mental Model

1. The adoption problem: “Nexus supports it” is not an operating model

An organization sees a new recipe in the Nexus UI and concludes that onboarding is finished. That conclusion skips the questions that actually determine whether builds will be reproducible: What is the package identity? Which HTTP/API protocol does the client speak? Does Nexus support proxy, hosted, and group for this exact protocol generation? Which realm or credential mechanism does the client require? Which metadata does Nexus generate? Can the content be moved, exported, imported, cleaned up, searched, and backed up with the same tools used for older formats?

Emerging formats change faster than mature ones. A feature can arrive in stages—proxy first, then hosted, then group, then improved authentication or new upstream compatibility. The safe operator habit is therefore capability discovery before configuration.

2. A five-gate mental model for every unfamiliar format

flowchart TD
C[Client protocol + version] --> I[Package identity + metadata]
I --> R[Repository types supported]
R --> A[Authentication + authorization]
A --> O[Operations: search backup migration cleanup]
O --> D[Adopt / pilot / defer]

The gates are sequential. If a client speaks the wrong protocol generation, no amount of repository privilege tuning will fix it. If hosted support exists but group support does not, one-endpoint client designs must change. If runtime storage works but export/import is unavailable or Pro-only, migration and disaster-recovery plans need another path.

3. Current capability map at the 3.95.2 baseline

A checkmark for a format is not permission to merge protocol generations. Conan 1 and 2 need separate thinking. Terraform provider artifacts have platform-specific identities and generated checksum/signature metadata. Swift can resolve Git URL declarations through registry replacement but its registry protocol is not a Git repository. Ansible collections are archives with Galaxy API metadata, not generic tarballs merely because the file extension is .tar.gz.

4. Conan: protocol generation is part of repository identity

Conan packages contain recipes and binary variants whose package IDs depend on settings, options, dependencies, and—with Conan 2—package type semantics. Nexus explicitly distinguishes Conan 1.x and Conan 2.0 behavior. Conan 1.x has proxy and hosted support but no group recipe; Conan 2 supports proxy, hosted, and group in current documentation. A Conan 2 client cannot simply be pointed at a Conan 1 proxy and expected to work.

The safest rollout records three independent facts: Nexus version/edition, Nexus recipe protocol generation, and Conan CLI major version. For hosted repositories, enable the Conan Bearer Token Realm only when you actually need client authentication. Keep revisions consistent with the chosen protocol. Do not “fix” compatibility by disabling TLS validation globally or by sharing one repository between Conan generations.

5. Ansible Galaxy: collection archives plus Galaxy v3 semantics

An Ansible collection is identified primarily by namespace.collection and version. The client communicates with a Galaxy API, not with a generic web directory. Nexus added Ansible support in 3.93.0 and currently supports proxy, hosted, and group repositories using the Galaxy v3 API. This is available in Community and Pro.

Authentication is also protocol-specific. Nexus exposes an Ansible Galaxy bearer-token realm. Current Sonatype examples encode username:password as Base64 for the client token field. Base64 is not encryption; it remains a credential. A production design should use least-privilege accounts and protected configuration or secret injection. In this chapter, any such token exists only in a permission-restricted temporary lab file and is deleted afterward.

6. Terraform: a registry is service discovery, modules, providers, platforms, checksums, and signatures

Terraform's registry protocol separates modules from providers. A module is a versioned source archive. A provider is a versioned executable distribution with operating-system/architecture dimensions and checksum/signature metadata. Nexus classifies those assets and rewrites registry responses so downloads remain inside the repository boundary.

The feature arrived incrementally: proxy in 3.88, hosted in 3.89, group in 3.90. Nexus 3.94 added OpenTofu plus Coder registry support, and 3.95 added a non-URL authentication flow using a TerraformBearerToken obtained from the repository token endpoint. This is an excellent example of why “Terraform supported since 3.88” is incomplete operational guidance.

7. Swift: registry protocol, not a Git mirror

Swift Package Manager traditionally consumes Git repositories, but the Swift Package Registry API provides a registry-oriented path. Nexus proxy support arrived in 3.89, hosted in 3.90, and group in 3.91. Current docs list Swift for both CE and Pro, require SPM 5.7 or later, and recommend 5.9+.

Nexus can replace SCM resolution with registry requests using --replace-scm-with-registry. For proxying, current Sonatype guidance is unusually specific: because there is no official public Swift registry, Nexus supports https://github.com/ as the remote storage URL and translates compatible package requests. Publishing uses the Swift package registry command and is currently not supported on Windows, even though Windows can consume packages.

8. What state changes when a new format is adopted?

9. Runtime support is not migration support

A format can be perfectly usable for upload/download while surrounding operational tooling lags. Sonatype's current self-hosted feature matrix marks Export Assets and Import External Files as Pro-only. Even with Pro, operators must verify format coverage and task semantics before planning migrations around those tasks. Configuration migration, instance migration, repository export/import, blob/database backup, and client repointing solve different problems.

For Community Edition, this means an adoption decision must include a supported backup/restore and migration strategy that does not quietly depend on Pro-only export/import. Chapter 25 will handle full backup/recovery; here the principle is simply to record the gap before production adoption.

10. Read-only inspection before creating anything

export NX_URL="http://127.0.0.1:8081"
export LAB="${TMPDIR:-/tmp}/nexus-ch12-inspect"
rm -rf "$LAB" && mkdir -p "$LAB"

curl -fsS "$NX_URL/service/rest/v1/status" > "$LAB/status.txt"
curl -fsS "$NX_URL/service/rest/v1/repositories" > "$LAB/repositories.json"
curl -fsS "$NX_URL/service/rest/swagger.json" > "$LAB/swagger.json"

grep -Eo '/v1/repositories/(ansible|terraform|swift|conan)[^" ]*' "$LAB/swagger.json"   | sort -u > "$LAB/emerging-repository-endpoints.txt" || true
cat "$LAB/emerging-repository-endpoints.txt"

The Swagger document is evidence from the running instance. A missing endpoint is more actionable than a screenshot from a different release. The command is read-only; it does not activate realms or create repositories.

11. Why this matters in DevOps

New ecosystems usually arrive because a team needs them now: an Ansible automation group, an infrastructure platform using Terraform providers, an iOS team adopting Swift registry semantics, or a C++ group migrating to Conan 2. Repository operators can either make that adoption evidence-driven or create a hidden supply-chain bypass. A precise format onboarding process creates a controlled endpoint, scoped credentials, reproducible client configuration, visible metadata, and a documented upgrade/migration boundary.

12. Knowledge check

13. Summary and next step

Emerging-format adoption is a compatibility exercise before it is a repository-creation exercise. Conan, Ansible, Terraform, and Swift each encode identity and client behavior differently, and their Nexus capabilities arrived over different release lines.

Lesson 2 turns that model into a disposable workflow: one native Ansible collection path, one Terraform registry fixture/upload path, and inspection fixtures for Conan and Swift.

Official references and version notes

• Sonatype: Download and 3.95.0–3.95.2 release notes.
• Sonatype: Self-Hosted feature matrix.
• Sonatype: Conan Repositories.
• Sonatype: Ansible Repositories, repository creation, and client configuration.
• Sonatype: Terraform Repositories, repository creation, client configuration, and CLI usage.
• Sonatype: Swift Repositories, repository creation, and SPM configuration.
• Sonatype: Nexus Repository API Reference.
• Sonatype: Repository Export and Repository Import — verify current Pro entitlement and format coverage before adoption.

Version-sensitive statements were rechecked on 2026-08-26. The mandatory lab pins Nexus Repository 3.95.2, which Sonatype's current download page lists as the latest downloadable self-hosted release and whose release notes date it to 2026-08-21. Java 21 remains the current Nexus runtime requirement. The mandatory path uses Community-compatible Ansible Galaxy and Terraform behavior and avoids depending on Pro-only export/import, user-token, staging, HA, or content-replication features.