You should be using an existing scripting language as your configuration language.
Seriously, Every single fucking stupid infrastructure-deployment-tool/"platform" whatever has it's own, dumb in-house language that winds up basically re-implementing the programming language the tool is written in badly.
- Puppet: Has a stupid ad-hoc config language.
- Terraform: Has a stupid ad-hoc config language.
- SaltStack: Has a stupid ad-hoc config language.
- Ansible: Has a stupid ad-hoc config language.
If you're even considering implementing a tool like this, use a goddamn existing language for your configuration files.
You don't need to use the entire language, but at least use the language's lexer/parser (cf. json/javascript). That way, all existing tooling for the language will work for the config files (ask me about how saltstack happily breaks their API because you're not "supposed" to use it, despite the fact that they have public docs for it). Additionally, people won't need to figure out all the stupid corner cases in your terrible piecemeal configuration language.
Additionally, by making your configuration language an actual language, you also simplify a lot of the system design, because the configuration can act directly against your API. This means using your tool from other tools becomes much more straightforward, because the only interface you actually need is the API.
Pulumi made the mistake of immediately making remote state a paid-only feature. Even if it's not, from all the recent marketing I looked at everything useful required payment; for getting started with a project that's a non-starter.
On top of that, most of the worst parts of Terraform are no longer an issue with 0.12.
Its completely possible to host your state in S3 or a filesystem; it takes a bit of setup and there may be a few rough edges, but the effort or subscription is completely worth it. The secrets management alone makes it worth it, but their programming model is definitely the future. I think the fact that AWS just released their Cloud Development Kit is strong validation of the approach.
Seriously, Every single fucking stupid infrastructure-deployment-tool/"platform" whatever has it's own, dumb in-house language that winds up basically re-implementing the programming language the tool is written in badly.
If you're even considering implementing a tool like this, use a goddamn existing language for your configuration files.You don't need to use the entire language, but at least use the language's lexer/parser (cf. json/javascript). That way, all existing tooling for the language will work for the config files (ask me about how saltstack happily breaks their API because you're not "supposed" to use it, despite the fact that they have public docs for it). Additionally, people won't need to figure out all the stupid corner cases in your terrible piecemeal configuration language.
Additionally, by making your configuration language an actual language, you also simplify a lot of the system design, because the configuration can act directly against your API. This means using your tool from other tools becomes much more straightforward, because the only interface you actually need is the API.