I don't understand why people use config servers like this, instead of keeping it in version control. Keeping it in the repository allows me audit changes of everything. If you move it to an external service, you lose that. And even if the external service has an audit trail, now you have two sources of version control. My assumption why people would do this is because 1) they're told that's how it should be done 2) they have a slow deployment processes, where it takes too long to get the change merged & deployed. Anyway, I've very happily never used a config service, and I still remain unconvinced. :)

I’m Jeremy, cofounder of Config.ly. It’s like a CMS for your static variables / copy / constants so you can easily update them from a web UI instead of deploying code.

We’re software engineers and saw that the source of many bugs, incidents and time-sinks stem from hard-coding data. For example - waiting a day or longer for an iOS app store approval of a copy change, waiting hours on an internal CI/deployment process to bump a timeout during a traffic spike incident, or having the same dollar-cost value diverge while hard-coded on iOS, Android and web clients.

In an ideal world, data would be completely separate from code. Databases can do this but often aren’t used that way for good reasons (they can be cumbersome to wire-up, there are scale concerns about adding extra load to your DB, it’s risky to touch a production database, etc). So we built Config.ly.

It has a simple web interface to define Strings, Numbers, Booleans and JSON objects and arrays. We think it’s so simple that even non-technical folks can update basic Config data like copy and colors (so you can focus on code!). We have client libraries (in four techs and growing!) that fetch these values from the server and intelligently handle optimizations like caching.

It’s free to use (with genorous size and bandwidth caps) and getting started from sign-up to fetching values in your client should take < 5 minutes.

And we’d love to hear what you think!

I love this idea. I will express the ups and downs of it, and see if I'm missing something.

First, some background: I'm a heavy Django user. Django has settings that are loaded once at runtime and usually they're in version control (they're committed to the repo). That means that, if you want to change a value to a setting, you must commit to the repo and re-deploy. If you're using Kubernetes, this might take several minutes (re build the images, upload to the registry, replicate on all the pods, etc).

That'd be the advantage of this solution. Imagine you have to change a setting IMMEDIATELY (something bad happen). You must: * commit to the repo and push * wait for CI (tests, formatting, protocols of PR approvals in a team, etc) * wait for CD (build image, push to registry, replicate, etc) It can potentially take several minutes.

Now, the major drawbacks I see with this service are: * Security: do you guys feel confident/strong enough to store important data of the app? Go so far as hosting secrets for example? (We use the Secret Manager in AWS). * Latency: in our case we read confs only once when the WSGI server starts. Can you be fast enough? * Availability: if your site goes down, my app goes down. Can you ensure 99.9999 availability?

Anyways, this is definitively a needed service. It does have its challenges, but you guys are onto something for sure. Congrats!

So this is a static file server that one can upload a JSON file to? It would be less prone to errors if the JSON was auto-generated based on a dynamic form so the user doesn't have to worry about getting the JSON syntax right.

So if I understand correctly, I can define bits of JSON / values in your interface. Then when my client app loads it'll hit your service backend to fetch them.

Seems pretty interesting. In terms of how it works it seems similar to how LaunchDarkly fetches its feature flags.

In practice if we configured all small bits of data in here it'll happen at app startup and be on the critical path. Do you have some sense about the latency there?

I've built in house versions of this for a handful of roles. Frustratingly common problem.

Great that there's a free model, but would love to see a `hobbyist` tier as well. 50 QPS won't cut for a lot of folks.

edit: forgot a word

This is going to come across as dismissive, I don't mean it to - I'm sure im missing something. Is this more than a key value store with TTLs? Is it the UI over the top, the CMS that differentiates this from something like redis?

I'm so excited for this ^_^

I was just thinking that what we really want when we say "no-code" is the ability to think in terms of domain specific data structures instead of programming constructs.

How does the offline story look like? At a first glance, it seems things would not work if you're not connected to the internet or don't/can't have a connection to Config.ly

you know what also allows you to never hardcode your data again... a database.

spring cloud config is a good selfhosted alternative if u use java

Clean interface, easy to use, nice work!

Looks nice and simple. There's been so many attempts at these things: configuration management, api key management, secrets management.... They're all basically the same thing... But I guess the same can be said about a lot of tools

Something I can't find on the site--who are you? Where is your company located?

How easy is it to have different sets of values, running at the same time, so that we can point the client to one of the sets ? E.g. each set can contain a "theme" or can denote a client.

Features that would be nice to have: A/B Testing, Global config keys so Enterprise customers can use them across projects.

Is there a size limit, do clients download changes or entire file?

This is such a cool idea. A simple web based database. If you introduced tier pricing with additional features, I would be willing to pay for this.

undefined

undefined

Just use S3

I've seen this built as an in-house tool at every major tech company I worked at. Can't believe this hasn't been built as a standalone product yet. Imo, there are 3 main use cases that make this kind of system a must-have: 1. shipping critical changes that can't wait for CI/deploy pipeline. If you're at a company with more than 5 engineers or so, it probably takes you anywhere between 15 min to multiple days (for mobile clients) to get code from your laptop into production. In time-critical situations, this can be unacceptable. Maybe I have an alert banner that I need to show to all users NOW, (or perhaps a configurable subset of users). Having an online tool where I can change the alert_banner config from null to "We are experiencing outages due to an ongoing AWS issue. We expect a resolution by 3pm PST" is something that cannot wait for that deploy cycle. And sure, I can store it in S3 but then only people with AWS access can set it, which is quite problematic. 2. Non-engineers need access. Maybe I want my marketing person to be able to change the copy on my landing page. Rather than having them bug me every time they need a copy change, I'll just hand the keys to them, without giving them access to the code base or AWS 3. Nuanced codepath management (I don't know what else to call this). Feature flags are great, and every company has some system for this. However, I sometimes find myself in situations where I want finer-grain control than simple boolean flags. An example that came up at work recently: I was working on my company's zendesk integration. Inside of our zendesk webhook, we set a bunch of user tags every time that a ticket gets filed (maybe 30-50 tags). We found that one of the tags ("company_size"), which depended on clearbit to populate, was throwing errors and returning 500 due to frequent clearbit timeouts and improper error handling in our code. This needed to be resolved immediately. The ideal setup here: inside my webhook code, before executing any business logic, I pull a "tags_to_skip" config, and any tags included in that config never get populated. This would allow me to update the "tags_to_skip" config from [] to ["company_size"]. Realistically, we're not going to have a feature flag for every tag. And even if we did, it would not be ideal, because there'd be nowhere we can go to see the list of all tags that are currently being skipped. Eventually we threw too many errors and zendesk turned off our webhook, which caused major headaches for the support team.

I'm not sure if I did a great job of explaining that last use case :/

This type of tool is one of those things that you don't think you need, until you see it. Once you see the tool, you start seeing countless places in your work where you realize that a tool like this is extremely powerful. I just played around with config.ly, and I have to give major kudos on the ease of setup and use. Really great product!

Tony integrates Configly with his frontend to fetch the data

const configly = Configly.init('apiKEY');

LOL