docs: add RDE install script documentation + fix repo URLs#143
docs: add RDE install script documentation + fix repo URLs#143evoxmusic wants to merge 4 commits into
Conversation
- Add 'Using the Install Script' section to blueprint management docs covering the curl-based install approach, .config.rde.qovery.yml configuration, version pinning, and full component reference table - Add install script option to Customization accordion - Update admin setup guide to mention both template and install script approaches - Fix all GitHub repo URLs: evoxmusic/ -> Qovery/ (4 occurrences)
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
qovery-doc-mintlify-proxy | b264f7c | Jun 02 2026, 09:03 PM |
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
jpetitcolas
left a comment
jpetitcolas
left a comment
There was a problem hiding this comment.
Super promising! And blazing fast! We talked about it only a few hours ago! 🚀
| FROM your-org/your-base-image:latest | ||
|
|
||
| # Install all Qovery RDE tools (code-server, AI agents, runtimes, dev tools) | ||
| RUN curl -fsSL https://rde.qovery.com/install.sh | bash |
There was a problem hiding this comment.
Isn't it too dangerous for supply-chain attacks? What about allowing to pin the version of the install script and check the checksum based on a hard-written string? With something like:
ARG QOVERY_INSTALL_VERSION=2.74.1
ARG QOVERY_INSTALL_SHA256=a62446223a42e0dc577dcead8d7bafabca4c548d9c3a6db761c6709bc8f4b373
RUN cd /tmp \
&& curl -fsSL https://rde.qovery.com/install.sh@${QOVERY_INSTALL_VERSION} -o "qovery_install.sh" \
&& echo "${QOVERY_INSTALL_SHA256} qovery_install.sh" | sha256sum -c - \
&& bash qovery_install.sh| nodejs: "22" # Node.js 22 LTS | ||
| python: true # latest Python 3 | ||
| ruby: false # skip Ruby | ||
| go: "1.24.3" # Go 1.24.3 |
There was a problem hiding this comment.
I'm wondering if you shouldn't use an object, such as:
go:
version: "1.24.3"That could be more furture-proof, if you want to add extra options.
| | fzf | `fzf` | system | Fuzzy file finder | | ||
|
|
||
| <Tip> | ||
| The install script and forking the template repository are complementary approaches. Use the install script when you want to keep your existing base image and add RDE tools on top. Fork the template when you want full control over the workspace image from scratch. |
There was a problem hiding this comment.
How would the Dockerfile interact with the .config.rde.qovery.yml? The image is built while the config file is at the runtime, right?
There was a problem hiding this comment.
When reading this file, I still have a question in mind: how do you prevent supply chain attacks in the base Dockerfile? Perhaps adding a mention could reassure the potential readers. :)
- Add 'Integrity & Reproducibility' section documenting SHA256 verification, GPG-verified Node.js install, and the vendoring pattern for production - Update RTK default version from 'latest' to '0.42.0' in components table - Note that Qovery CLI and Skills version pinning is planned
- Document the <tool>_sha256_<arch> config keys for custom version checksums - Fix github_cli -> gh config key in example and components table - Fix skills -> qovery_skills config key in example - Add 'Using custom versions' subsection under Integrity & Reproducibility
- Add rde_user to config example and Available Components table - Add 'Custom workspace user' subsection with examples - Document RDE_USER env var and existing user detection
3 participants
Changes
New: Install Script Documentation
curl-based install approach.config.rde.qovery.ymlconfiguration file with version pinning supportFix: Repository URLs
evoxmusic/remote-dev-env-templatetoQovery/remote-dev-env-template(4 occurrences including the Terraform example)Context
The RDE portal now ships an install script at
https://rde.qovery.com/install.shthat users can add to any Debian/Ubuntu Dockerfile to install all Qovery RDE tools. This is an alternative to using the template base image or forking the template repository.