Remote modules​

Configuration repositories can now depend on protos and Starlark that live somewhere else. Declare the dependency in a CONFIGSPACE file, pin it to a tag, branch, commit or checksum, and let protoconf mod tidy resolve it into protoconf.lock and a local cache:

platform_protos = remote_repo(
    url = "github.com/acme/platform-protos",
    tag = "v1.4.0",
)

load("@platform_protos//platform/v1/service.proto", "Service")

The lock file is what makes a compile reproducible — commit it next to your configs. Remote Modules →

Staged rollouts​

A configuration change is a deploy, and v0.2.0 lets you treat it like one. Wrap a config in a ConfigRollout and it reaches a canary channel first, then a percentage of your fleet, with a cooldown between each stage:

def main():
    return ConfigRollout(
        value = ServerConfiguration(max_connections = 2000),
        default_cooldown_time = Duration(seconds = 300),
        stages = [
            RolloutStage(channel = "canary"),
            RolloutStage(percentile = 10),
            RolloutStage(percentile = 50),
        ],
    )

Agents started with -enable-rollout pick the first stage they match, hashing their own identity so the same host lands in the same bucket every time. Interrupting protoconf insert mid-rollout clears the plan and returns every agent to the stable config. Staged Rollouts →

Kubernetes ConfigMaps​

configmaps is a new key-value backend for both the agent and the inserter, so a cluster can distribute protoconf configs without running Consul, etcd or ZooKeeper alongside it:

protoconf agent -store configmaps -namespace protoconf

Running on Kubernetes →

One-shot reads, including over HTTP​

Not every consumer is a long-running service. GetConfig is the unary counterpart to SubscribeForConfig, for jobs, scripts and init containers. The agent also transcodes it onto its admin HTTP listener, so anything that can make an HTTP request can read a config:

curl http://localhost:4380/v1/config/myproject/server_config

Consuming Configuration Updates →

Telemetry you opt into​

OpenTelemetry export is now off by default and enabled with -enable-otel. An agent that is not asked to export traces installs no-op providers and contacts nothing. Prometheus metrics stay where they were, on /metrics, no flag required. Observability →

protoconf fmt​

One canonical layout for .pconf, .mpconf, .pinc, .proto-validator and .star files, and a -l mode to fail CI when something is unformatted:

protoconf fmt -w .

Formatting →

Two things to check when upgrading​

Configuration precedence. Every command now resolves configuration as flags > environment variables > config file > proto defaults. protoconf agent used to let a config file override PROTOCONF_AGENT_* environment variables; it no longer does. With repeated -config-file flags, the later file now wins.

Telemetry is off by default. An agent that used to reach your collector automatically needs -enable-otel now.

The full list is in What's New in v0.2.0, and the complete changelog is on the release page.

As always, we're on Discord if you hit anything.

We are excited to announce the launch of our new documentation site! We've been hard at work behind the scenes to make it easier for you to find the information you need.

The new site is more than just a fresh coat of paint. It's a fundamental rethinking of how we present information about our product. Our goal is to provide you with clear, concise, and complete information about how to use our services.

Here are some of the new features and improvements we've made:

Improved Navigation: We've restructured our content to make it easier for you to find what you're looking for. Each page now has a clear title and description, so you can quickly scan to find the relevant content.

Advanced Usage Guides: We've added in-depth guides for advanced usage, showing you how to take full advantage of our features. These guides provide step-by-step instructions and code examples in different languages.

Better Code Examples: Our new documentation includes better, more comprehensive code examples. We've included examples in Go, Python, Node.js, Rust, and Java to help you understand how to use our APIs in your own projects.

Thorough API Documentation: We've expanded our API documentation to cover all the features of our service. You'll find detailed descriptions of each API endpoint, along with request and response examples.

We hope you find this new documentation site helpful and easy to use. As always, we're here to help if you have any questions or feedback. Please don't hesitate to get in touch with us.

Happy coding!

Your protoconf Team