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.
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.
halyx:
providers:
cloud: { type: aws, region: eu-west-2 } # or azure, gcp
blob-stores:
invoices: { bucket: acme-invoices }
topics:
order-events: { name: orders }
subscriptions:
billing: { name: orders-billing }
@Component
class Billing {
@HalyxListener("billing")
void onOrder(String json) { // return = ack, throw = retry
bill(json);
}
}
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
}
}
Why Halyx
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.
A BlobStore is a BlobStore on S3, Azure Blob Storage and Cloud Storage. Point it at another provider and the code stays the same.
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.
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.
Differences are declared as capabilities rather than hidden, and unwrap hands you the native SDK client for anything provider-specific.
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.
Parallel transfers, batching, checksums, presigned URLs, message listeners, fail-open caches and Micrometer observability. A library, not a platform.
Services
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.
| Service | Halyx API | AWS | Azure | Google Cloud |
|---|---|---|---|---|
| Object storage | BlobStore | Amazon S3 | Azure Blob Storage | Cloud Storage |
| NoSQL documents | DocumentStore | DynamoDB | Cosmos DB for NoSQL | Firestore |
| Messaging | Publisher, Subscription | SNS, SQS | Service Bus | Pub/Sub |
| Events | EventPublisher | EventBridge | Event Grid namespaces | Eventarc Advanced |
| Streams | StreamProducer, StreamConsumer | MSK | Event Hubs (Kafka) | Managed Kafka |
| Functions | FunctionInvoker | Lambda | Azure Functions | Cloud Run functions |
| SQL databases | Database (JDBC) | RDS, Aurora | Azure Database, Azure SQL | Cloud SQL |
| Caches | Cache | ElastiCache | Azure Cache / Managed Redis | Memorystore |
| Parameters & secrets | ParameterStore | SSM, Secrets Manager | App Configuration, Key Vault | Parameter Manager, Secret Manager |
Also: any Kafka cluster, PostgreSQL, MySQL, SQL Server, Redis or Valkey server, and HashiCorp Vault.
How it works
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.
Spring Boot
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.
<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
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.
| Halyx | Spring Cloud AWS, Azure, GCP | Dapr | MultiCloudJ | |
|---|---|---|---|---|
| Clouds | AWS, Azure, Google Cloud | One per project | Many, through components | AWS, Google Cloud, Alibaba Cloud |
| Languages | Java | Java | Any | Java |
| One API on AWS, Azure and Google Cloud | Yes | No: one project per cloud | Yes | No Azure |
| Runs inside your application | Yes | Yes | No: a sidecar | Yes |
| Same behaviour checked on every cloud | Yes, on real clouds | No | Varies by component | Not documented |
| SQL, caches, Kafka and secrets with IAM logins | Yes | Per cloud | Partly | No |
| Native SDK client available | Yes | Yes | No | Not documented |
| Spring Boot starter | Yes | Yes | Yes | No |
AI skills
The repository ships skills as plain Markdown. Claude Code runs them as skills; other assistants can follow them as instructions.
/halyx-ai-create
Builds a new Spring Boot service that runs on AWS, Azure and Google Cloud from one jar, with tests on each cloud’s emulators and, if asked, a Helm chart and IAM.
/halyx-ai-migrate
Moves an existing Spring Boot service from a cloud’s SDK, or Spring Cloud AWS, Azure or GCP, to Halyx, one reviewed step at a time.
/halyx-ai-review
Finds anything that still ties a Halyx service to one cloud and gives a verdict per cloud. Read-only.
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