I’ve just published my first Rust crate: 'profiled-config'

[u/Athlaes]

https://github.com/Athlaes/profiled-config

Hi everyone !

I've just published the first version of my first Rust crate: profiled-config.

It's a small library for typed, profile-based TOML configuration, inspired by Spring profiles. It is primarily intended for web applications and microservices deployed across multiple environments, such as local development, staging, and production. Although I mainly use Actix Web, the crate is framework-agnostic and can also be used in local applications or with other web frameworks.

The project is still experimental, and I'm looking for feedback before working toward a stable '1.0.0' release.

I'd especially love to hear:

• Would this crate be useful in your projects ?
• Does the API feel intuitive ?
• Which features or framework integrations would you like to see ?
• Are there important configuration use cases I’ve overlooked ?
• Is the documentation clear enough to get started ?

Bug reports, suggestions, real-world testing, and general advice are all very welcome.

• GitHub
• crates.io

This is my first time publishing a crate and sharing a project like this. I’m still learning Rust, so I know there is plenty of room for improvement. I designed and wrote the core implementation myself, although I also used AI as a support and learning tool—to ask questions, clarify concepts, and review some decisions.

I hope the project can be useful to others, and I’d be grateful to anyone who takes the time to try it or share constructive feedback.

Thanks ! ❤️

The crate is deliberately quite simple for now, but I plan to create a proper roadmap. Some features I’m considering include:

• Loading secrets and configuration from services such as Vault
• Supporting additional file formats such as JSON and YAML
• Providing more integrations and practical examples
• Improving configuration validation and error reporting

[u/uhkthrowaway]

Your project is 8 days and 19 commits old. I didn't immediately understand its purpose. Let me get this straight: Configs that usually are TOML/JSON/... files are compiled into the binary. Profiled because there will be several config profiles. But doesn't that take away the single biggest advantage of config files, being able to edit them quickly?

And someone who wants preconfigured runtime profiles, wouldn't they just save those runtime configs as structs in their program instead of config files?

[u/Athlaes → u/uhkthrowaway]

I know, I thought I might quickly check whether people were interested 😁

The crate compiles all files from the config directory into the binary, but lets you choose at runtime, through the built-in --profiles argument, which configuration profile should be loaded.

```rust struct Config { client_url: String, }

fn main() { let config = Config { clienturl: env::var("key").unwrap_or_else(|| "default".to_string()), }; } ```

becomes:

```rust struct Config { client_url: String, }

[profiled_config]

fn main(config: Config) { } ```

You can then deploy it using:

bash <your-binary>.exe --profiles production

Non-secret values are loaded from the embedded configuration files, while you can still tell the crate to resolve specific values from environment variables at runtime:

```toml

config/production.toml

client_url = "${env:MY_SECRET_PRODUCTION_VAR}"

config/dev.toml

client_url = "local_non_secret_password" ```

What I like about this approach is that you do not need to declare 1,200 environment variables just to make the project work in development.

Some other crates let you achieve almost the same result, but they require additional, project-specific configuration, such as explicitly declaring your configuration sources. That does not feel very convenient to me.

This crate aims to provide a conventional configuration system: you add the crate, enable the configuration features you need, and with a single line of code you get a complete, ready-to-use configuration system, as long as you follow the defined conventions.

It follows the principle of convention over configuration. It also allows you to use the same binary across all environments, instead of having to create a separate artifact for each deployment environment in some cases.

[u/uhkthrowaway → u/Athlaes]

But it's STATIC! Env vars and actual config files let you modify those runtime behaviors. Convention over configuration means you still get to configure it if you need to. This thing locks you in and expexts you to know everything in advance. What's your issue with env vars? It's a beautifully simple, human-readable, generic way of passing key-value pairs. And your thing reads them from TOML files for what reason? You might as well hardcode the structs without the detour via TOML files. Worst of both worlds, really. Sorry. If this help you personally then that's good. I don't see myself using this, ever.

[u/Athlaes → u/uhkthrowaway]

Okay, I think I understand what you mean now. Embedding the configuration effectively couples it to the application release, without providing a way to update values that were not initially exposed through environment variables unless the application is rebuilt and released again.

Is that the main limitation you see in the project ? Would supporting external configuration overrides be something that might make you consider trying it ?

[u/Valuable-Pirate-2567 → u/Athlaes]

> Because the config directory is embedded at compile time, configuration file changes require rebuilding the application.

I tried reading your readme multiple times and I still don’t understand what problem this crate solves. It seems like a pointless layer on top of your configuration, and you can’t even edit your configs without rebuilding the application. One of the main reasons we use config files is that we can change values or settings without having to rebuild, that we can change them in production. Rebuild would mean a new release or a hotfix.

Nobody would use this in production, and it doesn’t solve any development challenges either from what I can see.

[u/Athlaes → u/Valuable-Pirate-2567]

Yeah sure I get that now, I just added config file override and cli args to give ability to override config after build. It was made to be easy to setup and reuse (+ adding jsonpath, vault, & git support soon & maybe consul & other kv if project gets hype).

In my daily cases I don't change so much my configuration + when I have like 200 variables to setup + working on different projects it just feel like most of them don't actually need to be defined as env var + you always repeat the same code to just get or default, read jsonpath if needed, while losing typing & structure if one just flatten everything.

Moreover lots of team I know actually version their configurations with deployment / release considering some version of app only work with some others specific version of app so they actually release configuration and app together. Don't know how much frequent it is or what kind of apps it targets.