Inject Custom Config Files Easily With Volume Mounts

The Hassle of Custom Configurations in Stellar Quickstart

If you've been working with Stellar Quickstart, you know how powerful and flexible it is. However, when you need to fine-tune its behavior with custom configuration settings, like adjusting specific limits, the current process can feel a bit like a detour. Currently, to inject your custom config settings, such as specific limits configurations, you're faced with a few options, none of which are particularly streamlined for quick testing or experimentation. You typically need to add a new settings file directly into the repository, specifically within the local/core/etc/config-settings/p25/ directory. After placing your file there, you then have to go through the process of building a new image. This could involve pushing your changes to a branch and letting the pull request build handle it, running a local make build command, or even creating a new Docker image that inherits from the stellar/quickstart base image and manually copies in your settings file. While the latter approach avoids rebuilding the entire base image, it still requires extra steps. Finally, once your custom image is ready, you reference your custom settings file using the --limits option when you launch the container. This entire workflow, while functional, creates a noticeable friction for users who simply want to test out a custom configuration without the overhead of building custom images or forking the entire repository. It's an extra hurdle that can slow down development and testing cycles, especially when you're just tweaking a few parameters.

A Simpler Way: Runtime Configuration Injection

Imagine a world where applying custom configuration settings is as simple as mounting a file. That's precisely the enhancement we're proposing: support for injecting custom config settings files at runtime via a volume mount. The idea is to designate a specific path, perhaps /config-settings/, within the container where any configuration files placed there are automatically recognized and picked up by Stellar Quickstart. This would dramatically simplify the process. Instead of the multi-step image building routine, you could simply run your container with a command like this:

docker run -v ./my-settings:/config-settings stellar/quickstart --limits /config-settings/my-settings.cfg

In this scenario, ./my-settings would be a directory on your local machine containing your custom configuration file, my-settings.cfg. By mounting this local directory to /config-settings/ inside the container, Stellar Quickstart could then directly access and utilize your custom settings via the --limits flag. This approach offers immense flexibility, allowing developers to iterate rapidly on configurations without ever touching the image build process. It’s a direct, on-demand method that respects your time and streamlines your workflow. This feature would be particularly beneficial for scenarios like A/B testing different configurations, debugging specific performance issues, or simply tailoring the quickstart environment to very specific needs without creating a myriad of custom Docker images. The ease of use is the primary benefit here, making advanced configuration accessible to a wider range of users and use cases. The goal is to make advanced customization as straightforward as possible, lowering the barrier to entry for optimizing the Stellar Quickstart experience.

Exploring Alternatives and the Path Forward

While the proposed volume mount solution offers a significant improvement, it's always wise to consider the existing alternatives and other potential avenues. The first alternative, naturally, is to continue with the current workflow. This means sticking to the established method of building custom images or forking the repository whenever custom configurations are needed. This approach is reliable and well-documented, but as we've discussed, it lacks the speed and agility that many users desire for quick testing and iteration. Another option, particularly when custom limits aren't absolutely critical, is to simply use the --limits unlimited flag. This bypasses the need for any custom configuration file altogether, providing a broad, unrestricted environment. However, this isn't suitable when specific, fine-grained control over limits is a requirement for testing or development.

Beyond these, two other interesting alternatives have been considered. The first is adding a --limits-json option directly to the quickstart command. This would allow users to pass their custom limits as a JSON string directly on the command line. The quickstart image could then internally write this JSON to a temporary file, which would then be used by the --limits option. This avoids the need for volume mounts entirely but might become cumbersome for larger or more complex configurations, as command-line arguments can become unwieldy. The second alternative focuses on integrating this functionality into the stellar-cli. This would mean making it a feature accessible through the stellar container start command rather than directly within the quickstart container's parameters. This could offer a more cohesive user experience if you're already heavily invested in the stellar-cli ecosystem. However, it might also mean that users not using the stellar-cli would miss out on this convenient feature. Ultimately, the volume mount approach strikes a good balance between simplicity, flexibility, and broad applicability across different user setups. It leverages existing Docker capabilities and provides an intuitive way for users to manage their configurations. We believe this feature will significantly enhance the user experience by reducing friction and enabling faster, more efficient development and testing cycles with Stellar Quickstart.

For more information on Docker volume mounts and how they can be used to manage configurations, you can refer to the official Docker documentation on volumes. Additionally, exploring the Stellar documentation can provide further context on how Stellar integrates with containerized environments.