Conformance-tested on real AWS, Azure and Google Cloud accounts

One Java API for every cloud

Halyx gives Java microservices one consistent way to use storage, NoSQL, messaging, events, Kafka streams, functions, SQL, caches, parameters and secrets on AWS, Azure and Google Cloud. The clouds keep their own SDKs and strengths. Your code stops depending on them.

  • Java 21+
  • Spring Boot 3.5 & 4
  • Apache-2.0
try (Halyx halyx = Halyx.builder()
        .register("aws", ProviderConfig.of("aws").region("eu-west-2"))
        .register("gcp", ProviderConfig.of("gcp")
                .property(GcpProperties.PROJECT_ID, "acme-prod"))
        .build()) {

    BlobStore invoices = halyx.provider("aws").blobStore("acme-invoices"); // S3
    Publisher events = halyx.provider("gcp").publisher("order-events");   // Pub/Sub

    invoices.put(BlobKey.of("2026/42.pdf"), BlobContent.ofFile(pdf));
    events.publish(OutgoingMessage.builder(json)
            .attribute("type", "invoiced").build());

    try (Blob blob = invoices.get(BlobKey.of("2026/41.pdf"))) {
        blob.content().transferTo(out);
    } catch (NotFoundException e) {
        // the same exception on S3, Azure Blob Storage and Cloud Storage
    }
}
9cloud services
3clouds, plus Vault and in-memory
1API and error model
0passwords, sidecars or agents

Why Halyx

Portable code, not just portable business logic

Most “cloud-agnostic” services aren’t. The code around the business logic is written against one cloud’s SDK, each with its own types, error codes, retry rules and consistency quirks. Halyx makes that code portable too, without giving up what each cloud does well.

One API per service

A BlobStore is a BlobStore on S3, Azure Blob Storage and Cloud Storage. Point it at another provider and the code stays the same.

Same behaviour, proven

Conditional writes, versions, ordering, expiry, retries and errors mean the same everywhere. One conformance kit per service checks every provider, on emulators and on real clouds.

Several clouds in one service

Each cloud is a named provider, so one microservice can store files on S3, publish to Pub/Sub and cache in Azure, with one error model and one set of tests.

No lowest common denominator

Differences are declared as capabilities rather than hidden, and unwrap hands you the native SDK client for anything provider-specific.

Passwordless by default

Databases, caches and Kafka log in with AWS IAM, Microsoft Entra ID or Google IAM, with tokens refreshed before they expire. Keys and passwords you do keep are read from a parameter store as they’re used, so a rotation takes effect without a restart.

Production behaviour built in

Parallel transfers, batching, checksums, presigned URLs, message listeners, fail-open caches and Micrometer observability. A library, not a platform.

Services

Nine services, three clouds, one API

Which cloud serves each resource is configuration: the provider type, region and resource names. Every service also has an in-memory provider for fast tests.

ServiceHalyx APIAWSAzureGoogle Cloud
Object storageBlobStoreAmazon S3Azure Blob StorageCloud Storage
NoSQL documentsDocumentStoreDynamoDBCosmos DB for NoSQLFirestore
MessagingPublisher, SubscriptionSNS, SQSService BusPub/Sub
EventsEventPublisherEventBridgeEvent Grid namespacesEventarc Advanced
StreamsStreamProducer, StreamConsumerMSKEvent Hubs (Kafka)Managed Kafka
FunctionsFunctionInvokerLambdaAzure FunctionsCloud Run functions
SQL databasesDatabase (JDBC)RDS, AuroraAzure Database, Azure SQLCloud SQL
CachesCacheElastiCacheAzure Cache / Managed RedisMemorystore
Parameters & secretsParameterStoreSSM, Secrets ManagerApp Configuration, Key VaultParameter Manager, Secret Manager

Also: any Kafka cluster, PostgreSQL, MySQL, SQL Server, Redis or Valkey server, and HashiCorp Vault.

How it works

Your code depends on Halyx. Configuration picks the cloud.

The same build can run on AWS in one region and on Azure in another, move a single bucket to another cloud without touching code, fail over with a plan that is realistic rather than theoretical, and run its tests against the in-memory provider and emulators.

  • Data residency: the same service on AWS in one country, Azure or Google Cloud in another
  • A credible exit plan for DORA, PRA SS2/21 and APRA CPS 230
  • One build for products installed into each customer’s own cloud
See the portable microservice sample →
your microservice
Halyx API BlobStore · DocumentStore · Publisher · Subscription · EventPublisher · StreamProducer · FunctionInvoker · Database · Cache · ParameterStore one API · one error model · one set of tests
AWS Azure Google Cloud
+ HashiCorp Vault · in-memory

Spring Boot

A starter for Spring Boot 3.5 and 4

Beans from halyx.* properties, @HalyxListener message listeners, Spring Data repositories on DynamoDB, Cosmos DB and Firestore, R2DBC, @Cacheable, function invokers, health checks, Micrometer metrics and tracing, and spring.config.import=halyx:<store> for parameters and secrets.

In Kotlin, listeners can be suspend funs and repositories return Flows. Keys and passwords can come from a parameter store with secrets, on any cloud.

The orders database is a regular DataSource bean, so JPA, JdbcTemplate and Flyway use it unchanged.

pom.xml
<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>dev.halyx</groupId>
      <artifactId>halyx-bom</artifactId>
      <version>1.1.0</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
  <dependency>
    <groupId>dev.halyx</groupId>
    <artifactId>halyx-spring-boot-starter</artifactId>
  </dependency>
  <dependency>
    <groupId>dev.halyx</groupId>
    <artifactId>halyx-aws</artifactId>   <!-- or halyx-azure, halyx-gcp -->
  </dependency>
</dependencies>

How it compares

A library inside your application

Halyx is built for Java teams that want one API on AWS, Azure and Google Cloud, with the same behaviour checked on each, all inside their own application. The others fit different needs: Dapr for services in many languages, or for workflows and actors; Spring Cloud for a service that will only ever run on one cloud; MultiCloudJ for Alibaba Cloud.

HalyxSpring Cloud AWS, Azure, GCPDaprMultiCloudJ
CloudsAWS, Azure, Google CloudOne per projectMany, through componentsAWS, Google Cloud, Alibaba Cloud
LanguagesJavaJavaAnyJava
One API on AWS, Azure and Google CloudYesNo: one project per cloudYesNo Azure
Runs inside your applicationYesYesNo: a sidecarYes
Same behaviour checked on every cloudYes, on real cloudsNoVaries by componentNot documented
SQL, caches, Kafka and secrets with IAM loginsYesPer cloudPartlyNo
Native SDK client availableYesYesNoNot documented
Spring Boot starterYesYesYesNo

Write it once. Run it on any cloud.

Add the dependencies, register a provider and make your first calls in a few minutes.

$ git clone https://github.com/halyx-dev/halyx.git && cd halyx && mvn verify