Deploy to localstack

[petabook]

Hello. I'm seeking a straightforward method to deploy my instance of the ref arch to LocalStack (and yes, I understand that I'll have to use the paid version of LocalStack, and not everything is going to work).

The approach shown at demo-localstack uses mixins. How can I apply this approach to the ref arch dynamically, so that the mixin/localstack.yaml is only included if, say, an environment variable like DEPLOYMENT_TARGET is set to localstack? And, generally speaking, is this the right approach at all?

[osterman]

We don’t primarily use LocalStack ourselves, so we can’t personally attest to the reference architecture running that way. However, @hans-d (a reference architecture user) has successfully set it up entirely using LocalStack. To better guide you, I’d love to understand more about what you’re trying to achieve. One straightforward approach would be to create a localstack stage, similar to how you define dev, staging, and prod. From there, you could import the necessary services from your catalog into that stage for testing with LocalStack. Let me know how I can help!

[Benbentwo]

You could probably use a mixin file, or some stage - like @osterman said, and import a file that conditionally overrides to point at localstack.

e.g.

{{ if eq (getenv "DEPLOYMENT_TARGET") "localstack" }}
terraform:
  providers:
    aws:
      region: "us-east-1"
      access_key: "test"
      secret_key: "test"
      s3_use_path_style: false
      skip_credentials_validation: true
      ...
{{ end }}

Essentially wrapping it all in an env, that would I think, handle the case you're talking about.

The reason we don't do things like this typically though, is it becomes environment specific for the stack configuration - someones machine has a different source of truth than someone else's (based on env vars). This goes against the idea of gitops and git being the source of truth.

Similar to @osterman - whats your goal? might be an easier way to accomplish that task.

[Benbentwo]

Note the atmos settings here: https://atmos.tools/core-concepts/stacks/templates/

[petabook]

I’m concerned that the feedback loop is too lengthy. This is a general issue I have with IaC and is not specific to the ref arch.
If I deploy the wrong configuration to AWS, it could take ions to roll back, especially with the account deletion rate limits they have, etc. I would like a method to deploy the entire ref arch to LocalStack, make changes, redeploy, fix errors, and iterate. Essentially, I want to accelerate the development cycle.

[osterman]

In my experience, it’s similar to running k3s or ACT: while it provides a solid local feedback loop, there are significant differences from the real environment.

For example, with Kubernetes, key aspects like volumes, ingress, and TLS behave differently and have cloud-specific bindings, and once enough differences accumulate, the value of local testing diminishes since it no longer reflects production. Simple POCs work really well, but doing much beyond that is difficult.

We’ve encountered similar challenges with ACT. The slow feedback loop of GitHub Actions makes a local testing option appealing, but in practice, everyone I see who tries ACT eventually abandons it because workflows that pass locally may fail on GitHub and vice versa. While ACT can be useful in specific cases, as a general solution, it’s not something we can confidently support—its effectiveness depends heavily on the complexity of the workflows and the services involved.

Anyways, definitely agree it would be great to have, and we’d be open to exploring it with you through our Professional Services. However, it’s not something we currently support.

[petabook]

How about replacing command: tofu with command: tflocal in atmos.yaml?

[hans-d]

We are using some local overrides in our components, to specify if certain functionality is available or nor, and adjust the component accordingly. (eg budgets cannot be used on localstack).
Note that some additional env vars are needed in addition to what tflocal is supplying, because of the cloudposse aws util provider.
So still some work in progress to get everything working properly, but we can run the full bootstrap / cold start

[hans-d]

doing it on code level, so we dont have to worry about additional mixins / we can just copy over the normal config as just in regular aws deployments. (we did create a sperate "local" org to set some other defaults and be able to run some in parallel)

[petabook]

Thank you everyone, I've made significant progress and will be publishing my "how-to" soon.

[petabook]

Here's my How-To guide for running the Cloud Posse Ref Arch on LocalStack. Enjoy!
https://github.com/petabook/cloudposse-ref-arch/blob/main/docs/howto-localstack.md

[osterman]

@petabook: Wow, this is great! We'll review internally and see how we can adopt parts of this in our documentation.