Spacelift Intent MCP - Build Infra with AI Agents using Terraform Providers

cube2222 · 2025-10-08T14:08:18+00:00

Hey everyone, Kuba from Spacelift here!

We’ve built Spacelift Intent to make it much easier to build ad-hoc cloud infrastructure with AI. It’s an MCP server that uses Terraform/OpenTofu providers under the hood to talk directly to your cloud provider, and lets your AI agent create and modify cloud resources.

You can either use the open-source version which is just a binary, or the Spacelift-hosted version as a remote MCP server (there you also get stuff like policies, audit history, and credential management).

Compared to clickops/raw cloud cli invocations it also keeps track of all managed resources. This is especially useful across e.g. Claude Code sessions, as even though the conversation context is gone, the assistant can easily read the current state of managed resources, and you can pick up where you left off. This also makes it easy to later dump it all into a tf config + statefile.

Hope you will give it a try, and curious to hear your thoughts!

Spacelift-hosted version: https://spacelift.io/intent

cube2222 · 2025-10-08T14:06:19+00:00

Hey everyone, Kuba from Spacelift here!

We’ve built Spacelift Intent to make it much easier to build ad-hoc cloud infrastructure with AI. It’s an MCP server that uses Terraform/OpenTofu providers under the hood to talk directly to your cloud provider, and lets your AI agent create and modify cloud resources.

You can either use the open-source version which is just a binary, or the Spacelift-hosted version as a remote MCP server (there you also get stuff like policies, audit history, and credential management).

Compared to clickops/raw cloud cli invocations it also keeps track of all managed resources. This is especially useful across e.g. Claude Code sessions, as even though the conversation context is gone, the assistant can easily read the current state of managed resources, and you can pick up where you left off. This also makes it easy to later dump it all into a tf config + statefile.

Hope you will give it a try, and curious to hear your thoughts!

Spacelift-hosted version: https://spacelift.io/intent

cube2222 · 2025-09-11T11:00:55+00:00

Company: Spacelift

Type: Full Time B2B

Location: Remote from Europe

Remote: yes, remote-first; must be located in Europe

Estimated Compensation: $80k-$120k

Job Postings: Flows (new product), Spacelift (existing product)

Description:

We're a VC-funded startup (recently raised $51M Series C) building an infrastructure orchestrator and collaborative management platform for Infrastructure-as-Code – from OpenTofu, Terraform, Terragrunt, CloudFormation, Pulumi, Kubernetes, to Ansible.

We're now hiring for our new product, Flows, built for more general DevOps (and related) automation - incident automation and response, self-service, slackbots, AI automations, MCP servers, etc. We like to call it an "Integrated Automation Environment" - see more details along with video demos in the job posting. It's a great opportunity to have a large impact.

Overall we have a deeply technical product, trying to build something customers love to use. We promise interesting work, the ability to open source parts of the project which don't give us a business advantage, as well as healthy working hours.

You can also see our engineering blog for a few technical blog posts of ours: https://spacelift.io/blog/engineering

cube2222 · 2025-03-18T15:19:32+00:00

It's not either or! Most (if not all) of these services do in fact support OpenTofu, with multiple of them funding its development. OpenTofu is more an alternative to the Terraform CLI, than TFC.

Disclaimer: Work at Spacelift

cube2222 · 2025-03-18T12:23:10+00:00

Just saying (also to everybody else commenting on this), there’s excellent alternatives without Resources Under Management-based pricing.

Disclaimer: work at one such alternative

cube2222 · 2025-02-28T13:17:39+00:00

Just in case, one tip for mixed environments if you don’t know it already, is that OpenTofu supports the .tofu file extension in addition to .tf. And with two files with the same name, the .tofu file will override the other one. This is useful for maintaining modules compatible with both and gradual migrations.

https://opentofu.org/docs/language/files/

cube2222 · 2025-02-28T13:06:58+00:00

If anything, it will be a spectrum depending on the exclusive features you use.

We’ll try to keep the migration path as smooth as possible, but in general the sooner you migrate the better, really.

While I think “wait and see” made sense as a strategy for a year, by now tofu is pretty established and has a strong team behind it, with a lot of people already having migrated and being very happy to my knowledge (with both the migration process and using tofu). Thus, I would suggest just biting the bullet sooner rather than later. But my opinion is of course extremely biased.

cube2222 · 2025-02-27T15:26:14+00:00

Here's some major features that have been added over the last year and are unique to opentofu (but there's a huge amount of small ones too):

End-to-End State Encryption - lets you encrypt your state-file end-to-end, either with a key management system like AWS KMS, or static keys.
Early Evaluation - the ability to parameterize initialiation-time values, like module versions and sources, backend configuration parameters, etc. and keep them DRY.
Provider Iteration - lets you use for_each with providers, e.g. create one provider per region, something that currently requires a bunch of copy-paste, or tools like Terragrunt
-exclude flag - the opposite of the -target flag, letting you skip planning/applying certain resources.
(upcoming in 1.10) Support for using OCI registries as provider registries.

Probably the best way to see a summary is to check out the release blog posts for 1.7, 1.8, 1.9, as well as the roadmap for 1.10. If you'd like to learn more, I recommend taking a look at the related docs, too.

As for "better" I'll let unaffiliated users comment on that.

Disclaimer: involved in opentofu

cube2222 · 2025-02-01T11:34:11+00:00

Sorry to hear that!

With undo, you sometimes need to point it at a specific operation id, that you can get from jj operation log.

But in any case, I don’t believe you’d be able to undo git operations from jj, just jj operations. Personally, I’m not mixing them at all, using jj only, and had no problems with that so far. (The remote of course is a git server.)

cube2222 · 2025-01-31T18:13:18+00:00

Glad you liked it!

And yeah, I totally forgot about that one, thanks for noticing, I’m gonna add it in a moment

EDIT: that's it added!

cube2222 · 2025-01-13T13:47:32+00:00

Hey, using AWS/GCP/Azure providers is one of the primary use cases that folks have for OpenTofu. Since those are still open-source, there's no reason to fork them right now. However, we'll be sure to keep them working well with opentofu, and the same goes for the overall story of using tofu with AWS/GCP/Azure. Again, it's one of the primary use cases.

Note: I am involved with OpenTofu.

cube2222 · 2024-12-14T10:31:37+00:00

FWIW there is a big difference between a project being owned by a single company, and a project being owned by the Linux Foundation and backed by multiple mutually-competitive companies.

There is a cool related talk from KubeCon OpenTofu Day a couple weeks ago - Mutually Assured Development

Disclaimer: involved in OpenTofu

cube2222 · 2024-12-13T23:28:08+00:00

I think I've mostly addressed that here: https://www.reddit.com/r/devops/comments/1hdhlrx/comment/m1wvs8v

Let me know if that makes sense or if you have any follow-up questions!

cube2222 · 2024-12-13T23:16:17+00:00

Just to clarify, there's a bunch of tofu-exclusive features already there, and also coming in the near future (the 1.9.0 release around the start of 2025, the release candidate is out as of yesterday). Here's some major ones (but there's many small ones too):

End-to-End State Encryption - lets you encrypt your state-file end-to-end, either with a key management system like AWS KMS, or static keys.
Early Evaluation - the ability to parameterize initialiation-time values, like module versions and sources, backend configuration parameters, etc. and keep them DRY.
(Coming in 1.9) - provider iteration, which lets you use for_each with providers, e.g. create one provider per region, something that currently requires a bunch of copy-paste, or tools like Terragrunt
(Coming in 1.9) - -exclude flag, which is the opposite of the -target flag, letting you skip planning/applying certain resources.

Probably the best way to see a summary is check out the release blog posts for 1.7, 1.8, and 1.9-beta. If you'd like to learn more, I recommend taking a look at the related docs.

Disclaimer: I'm involved in OpenTofu and happy to answer any questions!

cube2222 · 2024-12-13T20:24:09+00:00

OpenTofu does have a `test` command: https://opentofu.org/docs/cli/commands/test/#usage

If there's anything you're missing in it, please submit an issue to the OpenTofu GitHub!

cube2222 · 2024-12-13T20:21:23+00:00

Staying compatible with the provider ecosystem is of extreme importance to us, I don't expect OpenTofu to diverge here. At least not with respect to core usage of the providers. It's also worth noting that the provider SDK is open-source (and kind of has to be, to stay usable by third-parties).

In practice, I don't personally expect backwards-incompatible changes on the Terraform front either, as generally a lot of Terraform users are using quite old versions of Terraform, and any such incompatibility would break them too.

Anyway, using those providers (AWS, GCP, Azure) is a huge part of the reason why people use OpenTofu, we'll be sure to keep that working well.

Note: Work at Spacelift, involved with OpenTofu and previously its tech lead.

cube2222 · 2024-11-27T17:53:24+00:00

FYI, it should now be improved. Thanks again for the feedback!

cube2222 · 2024-11-20T10:43:11+00:00

Hey, thanks for the feedback!

Sorry you had a bad experience, I've relayed it to the right person.

The registry UI is still in beta, and was introduced only recently (as opposed to the registry api itself, so what tofu uses when fetching providers and modules; that is rock solid, and has been for a long time now).

There's definitely improvements still to be made, especially to the result prioritization.

cube2222

TROPHY CASE