Support injecting custom config settings files via volume mount
Nobody has claimed this yet.
Assessment
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Newbie friendliness
- 52/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Quiet
- Tech stack
- docker
- Domain
- infrastructure
Research direction
Start with the settings location at local/core/etc/config-settings/p25/ and the quickstart container's handling of the --limits option. Verify the Docker volume mount at /config-settings/ can supply a custom settings file at runtime without rebuilding the image, and confirm the mounted file is used by the container.
Written by the indexing model from the issue text.
Description
What problem does your feature solve?
Currently, to use custom config settings (e.g., custom limits configuration), users must:
- Add a new settings file to the repository at
local/core/etc/config-settings/p25/ - Build the image using one of these approaches:
- Push to a branch and let the PR build it
- Run
make buildlocally - Create a new Docker image that inherits from
stellar/quickstartand copies in the settings file (avoids rebuilding the base image)
- Reference the settings file via the
--limitsoption when running the container
This workflow creates friction for users who want to quickly test with custom config settings without building custom images or forking the repository.
What would you like to see?
Support for injecting custom config settings files at runtime via a volume mount path that gets picked up automatically (e.g., /config-settings/).
This would allow users to run something like:
docker run -v ./my-settings:/config-settings stellar/quickstart --limits /config-settings/my-settings.cfg
What alternatives are there?
- Continue with the current workflow (build custom images or fork repo)
- Use
--limits unlimitedwhen custom limits aren't strictly necessary - Add a
--limits-jsonoption that accepts raw JSON text, allowing the quickstart image to write it to a file internally (no volume mount needed) - Inject the settings via
stellar container startcommand, making this a feature accessed through stellar-cli rather than quickstart directly
- Dominant language
- Shell
- Stars
- 222
- Forks
- 236
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 12
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from stellar/quickstart
-
Difficulty 4/5 3-5 days Newbie friendliness 48/100
stellar/quickstart#932 · 16 comments · 2 reactions ·
-
Difficulty 4/5 3-5 days Newbie friendliness 58/100
stellar/quickstart#923 · 2 comments ·
-
bug
Difficulty 4/5 3-5 days Newbie friendliness 35/100
stellar/quickstart#911 · 2 comments ·
-
feature request
Difficulty 5/5 Over a week Newbie friendliness 35/100
stellar/quickstart#907 · 1 comment ·
-
feature request
Difficulty 5/5 Over a week Newbie friendliness 35/100
stellar/quickstart#906 · 3 comments ·
All issues in stellar/quickstart
Similar issues
-
Update Vish to 1.1.5 Openpackage-update
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
oSoWoSo/vOid_Community_repOsitory#144 · 1 comment ·
-
help wanted new command
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
tldr-pages/tldr#24151 ·
-
PacReq: Rune IDE Openpackage request
Difficulty 2/5 1-3 hours Newbie friendliness 68/100
pacstall/pacstall-programs#9402 ·
-
[BUG] ci: the first prefetch-images.sh call runs before shard.txt exists, so it is always a no-op Openbug github-actions
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
-
update-request
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
msys2/MINGW-packages#31768 ·