[LFX Mentorship 2026 - Project Idea] "Project Melody" Resource types.

[mathieu-benoit]

The basic idea would be to:

1. Identify common resource types (i.e. open source databases, common cloud infra etc)
2. Define the output schemas and if applicable input schemas
3. Document them
4. Create provisioners for them

This would help with usage examples, general documentation and avoid many teams reinventing the wheel.

Current discussion between @chris-stephenson @Abhishek9639 and @mathieu-benoit to refine this potential LX Mentorship project.

[mathieu-benoit]

Questions / Thoughts:

• This should go there https://docs.score.dev/examples/resource-provisioners/ and not in default provisioners?
  • If validated, source code where the contributions will go: https://github.com/score-spec/community-provisioners
• It would be great to have some LocalStack examples https://github.com/localstack
• It would be ideal to have some Terraform and Pulumi examples

[Abhishek9639]

Thanks for the context @mathieu-benoit. This really helps clarify the direction.

Makes sense to keep these in community-provisioners better to keep the core clean and let the community layer build on top.
LocalStack examples sound like a great starting point. I'm thinking S3, SQS, and DynamoDB would cover the most common use cases happy to hear if you had other services in mind too.

Terraform and Pulumi would definitely round it out nicely for teams already using IaC. I'll dig into the existing
community-provisioners structure and docs.score.dev this week and come back with a clearer picture of what's missing and where we can add the most value.

[Abhishek9639]

After going through the community-provisioners repo and docs.score.dev/examples/resource-provisioners/, here's what I found:
What already exists:

S3 provisioner exists but it's Minio-based (default provisioner) no LocalStack variant yet Redis, Postgres, MySQL, MongoDB, Kafka, RabbitMQ, Elasticsearch are all covered in defaults Community provisioners have Dapr, GCP Pub/Sub emulator, LLM model, Redis (Helm-based) etc.

What's clearly missing (good scope for this mentorship):
For LocalStack:

s3 - LocalStack variant (community provisioner, both score-compose + score-k8s)
sqs - not present anywhere yet
dynamodb - not present anywhere yet
sns - not present anywhere yet

For Terraform / Pulumi:

No Terraform or Pulumi based provisioner examples exist anywhere in the repo yet good opportunity to add cmd:// based provisioners that shell out to terraform apply or pulumi up

This gives us a clean, well-scoped project filling the LocalStack gap for common AWS services and adding IaC-based provisioner examples. Happy to start with LocalStack S3 as a first PR to validate the pattern, then expand from there.
@mathieu-benoit @chris-stephenson does this scope make sense to you?

[mathieu-benoit]

Thanks! Yes I think we have 1 use case here where this could be implemented from score-compose (LocalStack) to score-k8s (Terraform/OpenTofu). Docs (Examples) and Blog post will be part of this scope too.

@chris-stephenson another use case that we could include here in addition to this one?

[chris-stephenson]

I'll focus on the first 3 points as it looks like you're both pretty far ahead with point 4.

The idea of Project Melody was to provide consistency and a common dev experience. Having a set of reference, opinionated resource types is an an important step in that direction.

I would therefore suggest the following approach for the 1st three points:

Start with identifying resource type that map to generic / system components:

• dns
• route
• environment
  etc

I would then focus on open source / "standard" components, e.g.:
Examples:

• PostgreSQL
• MySQL
• MariaDB
• Redis
• Valkey
• Elasticsearch
• OpenSearch
• AMQP (RabbitMQ)
• MongoDB
  etc

Next I would identify the most common proprietary resource type per Cloud provider / vendor, e.g

• S3, GCS, Azure Blob Storage
• PubSub, Event Manager
• DynamoDB, Firebase

I would also make sure that there is a proper review of how the resource types are used now. For example:

• Would it make sense to provide a connection string output for database types?
• What do do about systems that are protocol compatible but might not be feature compatible (ValKey and Redis for example)
• Should some types be factored out, e.g. PostgreSQL database and PostgreSQL user?
• Conventions around references between resources via params (e.g. route depends on a dns)
• Careful evaluation of the param schemas of all types - have good arguments as to why a param schema should exist and not be managed directly by the provisioner.

[Abhishek9639]

Thanks for the detailed breakdown @chris-stephenson. This really helps clarify the direction.
Makes sense to start with the generic types first and then build up to the open source and cloud-specific ones. And yeah, the design questions around connection strings and param schemas are going to be tricky good to think about them early.
Would be great to align on all of this on Monday with @mathieu-benoit. Looking forward to it.

[mathieu-benoit]

Thanks @chris-stephenson and @Abhishek9639, that's good insights and good context.

This is very important for Score in general, and has been discussed several times in the past. We will need to do that, that's for sure.

Now here is my out and loud challenge/questions for us:

1. For an LFX project, I think we need something more specific with less research and opened items.
2. Submitting an LFX project requires:
   a. Making sure that the mentee has clear guidance and get a well-scoped project
   b. Assuring that 2 Mentors (@Abhishek9639 + 1 Score Maintainer) get the bandwidth to support in both ways: proactive and reactive. I personally don't think I'll have the bandwidth, and not sure about the other Score Maintainers.
3. I'm not sure we are ready to submit something for tomorrow and we definitely need to anticipate the next cohort and be more prepared.

Again, don't make me wrong, important project and LFX mentorship is something we want to do, but is it the right timing and project?

What do you think @Abhishek9639 @chris-stephenson?

[Abhishek9639]

Thanks for being transparent about this @mathieu-benoit really appreciate it.
I completely understand the concerns. If the bandwidth isn't there right now to properly support a mentee through this, it makes more sense to wait and do it right rather than rush it.
I'm happy to continue contributing to Score in the meantime working through issues like #475 and #281 so that by the next cohort, we have a well-scoped project and I'm already familiar enough with the codebase to hit the ground running.
What do you think @chris-stephenson should we target the next term instead?

[mathieu-benoit]

For LocalStack, we'll need to see if there is any limitation in terms of license/access, apparently some changes happened on March 2026. Kumo seems to be a new alternative: https://medium.com/aws-in-plain-english/meet-kumo-a-free-no-account-local-aws-emulator-4a171b917401. Just sharing for future reference.

[Abhishek9639]

Thanks for flagging this @mathieu-benoit. Hadn't looked into the LocalStack license change closely, so this is really helpful. Makes sense that it could be a blocker if users need an account just to get started.
Kumo looks promising it's written in Go, MIT licensed, and runs on port 4566 so switching over shouldn't be too painful.
Also came across MiniStack and Fakecloud while looking into this, worth keeping on the radar as well.
I'll track how these shape up. Good to have it all noted down for when we revisit this.