DEV Community

Cover image for Floci: Run AWS Locally for Free, From a Spring Boot Developer's Perspective
Md Jamilur Rahman
Md Jamilur Rahman

Posted on

Floci: Run AWS Locally for Free, From a Spring Boot Developer's Perspective

#springboot #aws #programming #devtools

Every Spring Boot developer who works with AWS knows the pain. You write code that talks to S3, SQS, or DynamoDB. To test it, you either mock everything (and discover at deploy time that your mocks were wrong), or you point your tests at a real AWS account (and pray nobody deletes the wrong bucket).

LocalStack used to be the answer. Then in March 2026, LocalStack ended its free Community edition. According to Floci's blog, auth tokens became mandatory, security updates froze, and the open-source repo was archived. Thousands of CI pipelines that auto-pulled the latest image suddenly depended on a project being wound down.

Enter Floci, an MIT-licensed, free-forever local cloud emulator that launched in March 2026 and hit 16,900+ GitHub stars in four months.

What Floci Actually Is

Floci is a set of cloud emulators built with Quarkus Native (compiled with GraalVM Mandrel into a standalone binary). It runs AWS, Azure, and GCP services locally on your machine. No cloud account, no API keys, no telemetry.

For AWS specifically, Floci provides 68 services on port 4566, the same port LocalStack uses. This means if you already have LocalStack configured, switching is a one-line Docker image change.

Three products exist today:

  • floci: 68 AWS services (S3, SQS, Lambda, DynamoDB, RDS, ECS, ElastiCache, MSK, and more) on port 4566
  • floci-az: 22 Azure services (Blob, Queue, Table, Functions, Key Vault, Event Hubs, Service Bus) on port 4577
  • floci-gcp: 22 GCP services (Cloud Storage, Pub/Sub, Firestore, Datastore, Secret Manager, IAM) on port 4588

All three are MIT licensed and require zero credentials.

Why This Matters for Spring Boot Developers

If you build Spring Boot applications that integrate with AWS, your integration tests probably touch one or more of these services: S3 for file storage, SQS for messaging, DynamoDB for NoSQL, or RDS for relational databases.

Floci runs real engines, not mocks. This is the critical distinction:

  • Lambda runs in real Docker containers with actual AWS runtimes (Java, Python, Node.js, Go)
  • RDS spins up real PostgreSQL, MySQL, or MariaDB instances
  • ElastiCache runs real Redis
  • MSK runs real Kafka via Redpanda
  • OpenSearch runs real OpenSearch clusters

When your Spring Boot app connects to Floci's S3, it uses the same AWS SDK calls, the same SigV4 signing, the same HTTP protocols as production. If your code works against Floci, it will work against real AWS.

Performance Numbers

Floci is a native binary, not a JVM application. The numbers from their benchmark suite (1,925 SDK compatibility tests):

  • Startup: 24ms (vs LocalStack's 3.3 seconds)
  • Idle memory: 13 MiB (vs 143 MiB)
  • Docker image size: 90 MB (vs 1.0 GB)
  • SDK compatibility: 1,925 out of 1,925 tests pass, including 889 out of 889 Java SDK v2 tests

For CI pipelines, the 24ms startup matters. Your test job no longer wastes 3+ seconds waiting for the emulator to boot before the first test can run.

How to Use Floci With Spring Boot

Prerequisites: Maven Dependencies

For Maven (add the starter for each AWS service you use):

<!-- Spring Cloud AWS (Spring Boot 3.x) -->
<dependency>
    <groupId>io.awspring.cloud</groupId>
    <artifactId>spring-cloud-aws-starter-s3</artifactId>
    <version>3.2.0</version>
</dependency>

<!-- Add more starters as needed -->
<!-- spring-cloud-aws-starter-sqs for SQS -->
<!-- spring-cloud-aws-starter-dynamodb for DynamoDB -->

<!-- Testcontainers -->
<dependency>
    <groupId>org.testcontainers</groupId>
    <artifactId>testcontainers</artifactId>
    <scope>test</scope>
</dependency>
Enter fullscreen mode Exit fullscreen mode

Spring Boot 3.1+ manages Testcontainers versions in its BOM, so you do not need to specify a version. Each Spring Cloud AWS starter auto-configures its respective AWS client bean (for example, spring-cloud-aws-starter-s3 gives you an auto-configured S3Client).

Option 1: Docker Compose

The simplest approach. Add Floci to your docker-compose.yml:

services:
  floci:
    image: floci/floci:latest
    ports:
      - "4566:4566"
Enter fullscreen mode Exit fullscreen mode

Then point your Spring Boot app at localhost. Spring Cloud AWS exposes a global endpoint property that applies to all auto-configured AWS service clients (source: Spring Cloud AWS reference docs):

# application-test.yml
spring:
  cloud:
    aws:
      endpoint: http://localhost:4566
      region:
        static: us-east-1
      credentials:
        access-key: test
        secret-key: test
Enter fullscreen mode Exit fullscreen mode

For per-service overrides, you can also use spring.cloud.aws.s3.endpoint, spring.cloud.aws.sqs.endpoint, or spring.cloud.aws.dynamodb.endpoint.

Option 2: Testcontainers (Recommended for Spring Boot)

Spring Boot has first-class Testcontainers support since version 3.1. The Spring Cloud AWS project has already added Floci support to its integration test setup (PR #1604).

Floci prints a LocalStack-style Ready. log line at startup for Testcontainers compatibility (source: Floci migration guide), so the standard Wait.forLogMessage strategy works:

@SpringBootTest
@Testcontainers
class S3IntegrationTest {

    @Container
    static GenericContainer<?> floci = new GenericContainer<>(
        DockerImageName.parse("floci/floci:latest"))
        .withExposedPorts(4566)
        .waitingFor(Wait.forLogMessage(".*Ready.*", 1));

    @DynamicPropertySource
    static void configure(DynamicPropertyRegistry registry) {
        String endpoint = "http://" + floci.getHost()
            + ":" + floci.getMappedPort(4566);
        registry.add("spring.cloud.aws.endpoint", () -> endpoint);
    }

    @Autowired
    private S3Client s3Client;

    @Test
    void shouldUploadAndDownloadFile() {
        s3Client.createBucket(CreateBucketRequest.builder()
            .bucket("test-bucket").build());

        s3Client.putObject(PutObjectRequest.builder()
            .bucket("test-bucket").key("test.txt").build(),
            RequestBody.fromString("Hello Floci"));

        String content = s3Client.getObjectAsBytes(
            GetObjectRequest.builder()
                .bucket("test-bucket").key("test.txt").build())
            .asString(StandardCharsets.UTF_8);

        assertEquals("Hello Floci", content);
    }
}
Enter fullscreen mode Exit fullscreen mode

The @DynamicPropertySource pattern injects Floci's endpoint into your Spring context at test time. Your production code stays untouched.

Who Is Already Using It

This is not a toy project. Real teams have migrated:

  • Apache Camel swapped LocalStack for Floci across its entire AWS test suite. The camel-aws test suite dropped from 6.5 minutes to 4.5 minutes (PR #23404).
  • Spring Cloud AWS added Floci to its integration test setup (PR #1604).
  • Testcontainers for .NET shipped a first-party Floci module (PR #1690).
  • Quarkus AWS Services (Quarkiverse) ships testcontainers-floci as a dev-services provider.
  • Just Eat Takeaway.com migrated two open-source messaging projects.
  • UK Government teams at DEFRA, NHS Digital, and GOV.UK One Login adopted Floci.

When Apache Camel and Spring Cloud AWS trust a tool for their CI, that is a strong signal.

Floci vs LocalStack: The Honest Comparison

LocalStack still exists as a paid product. But the free Community edition is dead, and many teams need a free alternative.

Feature Floci LocalStack Community
Price Free forever Auth token required (March 2026)
License MIT Apache 2.0 (archived)
Security updates Active Frozen
Startup time 24ms 3.3s
Idle memory 13 MiB 143 MiB
Docker image 90 MB 1.0 GB
Java SDK v2 tests 889/889 pass Partial
Lambda Real Docker containers Partial
RDS Real PostgreSQL/MySQL Not available
ECS Real Docker tasks Not available
EKS Live k8s API (k3s) Not available

Floci's real-engine approach is its biggest advantage. When you test against mock S3, you might miss edge cases like multipart upload behavior, presigned URL validation, or bucket policy evaluation. Floci runs the actual protocol stack, so these scenarios work the same way locally as they do in production.

Floci + AI Coding Agents

One more thing worth mentioning. If you use AI coding assistants like GitHub Copilot or Claude Code to write cloud code, those agents need a safe place to test. Real cloud accounts mean real billing risk and credential leakage.

Floci gives agents a local cloud they can break without consequences. No credentials to leak, no bill to worry about, 24ms feedback loop. The agent writes code, runs it against Floci, verifies it works, then you review before deploying.

When Floci Might Not Be Enough

Floci emulates the control plane and data plane of AWS services. It does not replicate:

  • Network latency between regions
  • IAM propagation delays (though IAM is emulated, timing differs)
  • Service quotas and rate limiting behavior
  • Cross-account trust policies in complex setups

For most integration testing and local development, these gaps do not matter. For performance testing or security auditing, you still need a real AWS environment.

Getting Started 

# Install
curl -fsSL https://floci.io/install.sh | sh

# Start AWS emulator
floci start

# Set endpoint
export AWS_ENDPOINT_URL=http://localhost:4566

# Use it
aws s3 mb s3://my-bucket --endpoint-url http://localhost:4566
Enter fullscreen mode Exit fullscreen mode

Or with Docker:

docker run -d -p 4566:4566 floci/floci:latest
Enter fullscreen mode Exit fullscreen mode

Floci is free, MIT-licensed, and the community is active. The GitHub repository is at github.com/floci-io/floci.

Summary

For Spring Boot developers working with AWS, Floci solves three problems at once: no cloud bill during development, no mock-related false positives in tests, and no dependency on a dead free tier. The real-engine approach means your integration tests catch issues that mocks miss. The native binary speed means your CI pipeline runs faster. And the MIT license means it stays free forever.

If you are still pinned to an archived LocalStack image, the migration is one Docker image change. Your Spring Boot code does not need to change at all.

Sources:

Top comments (1)

Collapse
 
alexshev profile image
Alex Shev •

Local AWS-style workflows are valuable because they shorten the feedback loop before cloud complexity enters the picture. The trick is keeping the local path close enough to production that it catches real integration mistakes.