/
Application registry hosting approach

Application registry hosting approach

Purpose

This document evaluates different approaches for hosting an application registry for storing and distributing application descriptors across release, snapshot, and custom (feature) versions.

Scope

This SPIKE explores several candidate solutions:

  • S3 bucket with optional indexing

  • mgr-applications in FAR mode

  • GitHub repository or GitHub Packages

  • Artifact repositories like Nexus and JFrog Artifactory

Each solution is analyzed in terms of:

  • CRUD and API capabilities

  • Searchability (by name, id, releaseType)

  • Versioning

  • Access control

  • Availability, fault-tolerance, and scalability

Requirements

  • Ability to store descriptors in JSON format

  • CRUD operations over HTTP

  • Support versioning and custom naming

  • Search by id, name, releaseType

  • Optional authentication for reads/writes

  • High availability and fault tolerance (≥ 99.9%)

Evaluated Solutions

Option 1: Amazon S3 (with static website or index layer)

  • CRUD/API: RESTful via AWS SDK or CLI

  • Versioning: Optional S3 versioning or filename conventions

  • Search: Limited; requires naming conventions or external indexing (Athena/Glue)

  • Auth: IAM policies or public read

  • HA: 99.999999999% durability, multi-AZ availability

  • Pros: Simple, low cost, highly available

  • Cons: No native search/filtering without external indexing

Option 2: mgr-applications in FAR mode

  • CRUD/API: Full REST API for AD CRUD

  • Versioning: Supported via ID (<name>-<version>)

  • Search: Via API filters (name, releaseType, etc.)

  • Auth: No built-in auth in FAR mode, can be added via reverse proxy

  • HA: Requires DB + multi-AZ ECS/Beanstalk

  • Pros: Purpose-built, flexible querying

  • Cons: Requires DB, deployment & maintenance overhead

Option 3: GitHub repository (static JSON in Git)

  • CRUD/API: REST API or git operations

  • Versioning: Git commits + file-based versions

  • Search: File-level; filtering by path/name

  • Auth: Public or private via GitHub settings

  • HA: GitHub SaaS

  • Pros: Traceability, native versioning, low ops

  • Cons: No structured querying by metadata

Option 4: Nexus / Artifactory (self-hosted or cloud)

  • CRUD/API: Full REST API

  • Versioning: First-class artifact versioning

  • Search: Robust; search by name, version, properties

  • Auth: Role-based + anonymous read option

  • HA: Depends on setup; Pro versions support clustering

  • Pros: Structured storage, metadata tagging

  • Cons: Heavier setup and maintenance

Comparative Summary

Solution

CRUD / API Support

Search Capabilities

Versioning

Access Control

Availability

Notes

Solution

CRUD / API Support

Search Capabilities

Versioning

Access Control

Availability

Notes

Amazon S3

✅ Full via REST/CLI

⚠️ Limited (by key/prefix only)

✅ By object name or versioning

✅ IAM or public read

✅ 99.999999999% durability

Needs key naming convention or Athena for metadata search

mgr-applications (FAR)

✅ Full REST API

✅ Filter by name, id, releaseType

✅ Name includes version ID

⚠️ No built-in, proxy needed

⚠️ Depends on ECS/EKS/Beanstalk

Best functional fit but requires DB + deployment

GitHub Repository

✅ REST / Git

⚠️ File name/path based only

✅ Git commit + file naming

✅ Public or private repos

✅ GitHub-hosted

Simple setup, traceable, good for lightweight usage

Nexus / Artifactory

✅ Full REST API

✅ Rich (name, version, metadata)

✅ Built-in artifact versioning

✅ Role-based + anonymous opt

⚠️ Self-hosted / Pro for HA

Best for large scale or enterprise, heavier setup required

mgr-applications Deployment in FAR Mode

To deploy mgr-applications in FAR (Folio Application Registry) mode:

Purpose: FAR mode disables integration with Okapi, Kong, Kafka, and other FOLIO dependencies. It provides a standalone REST API to manage descriptors.

Required Environment Variables

FAR_MODE=true KONG_INTEGRATION_ENABLED=false OKAPI_INTEGRATION_ENABLED=false DB_HOST=<rds-hostname> DB_PORT=5432 DB_NAME=<db-name> DB_USERNAME=<db-username> DB_PASSWORD=<db-password> SERVER_PORT=8081 #Additional options may be required

Deployment Options

  • ECS Fargate or EKS: Run as a stateless container service

  • Elastic Beanstalk: Deploy as a Spring Boot JAR for managed EC2 + RDS PostgreSQL backend

  • PostgreSQL: Mandatory for descriptor persistence

  • Load Balancer: Terminate TLS, optionally enforce basic auth or JWT

Access & Security

  • No built-in auth in FAR mode

  • Secure using NGINX reverse proxy, AWS ALB rules, or API Gateway

  • Expose only necessary endpoints externally

HA and Reliability

  • Use RDS Multi-AZ with backups

  • Minimum 2 replicas of service with health checks