**Related issue:** Resolves#47488
Smoke tested a Render blueprint deploy using this branch:
<img width="655" height="216" alt="Screenshot 2026-06-30 at 12 11 25 PM"
src="https://github.com/user-attachments/assets/7f5b6e76-1aa6-4ae6-b96c-9757f7cf2baf"
/>
## What & why
The Render deployment blueprint provisioned its MySQL service from the
external
[`render-examples/mysql`](https://github.com/render-examples/mysql)
repo, whose Dockerfile pins `mysql/mysql-server:8.0.24`. MySQL 8.0.24
does not support nesting a `UNION` inside the right-hand operand of
another `UNION`, so host-detail queries fail with:
> Error 1235 (42000): This version of MySQL doesn't yet support 'nesting
of unions at the right-hand side'
This surfaced via the Vanta integration hitting `GET
/api/latest/fleet/hosts/:id` on a Render deployment.
This PR switches the `fleet-mysql` service to pull the official
`mysql:8.0.44` image directly (`runtime: image`), removing the
dependency on the external repo. 8.0.44 is Fleet's documented minimum
supported MySQL version and is what `docker-compose.yml` already uses
for dev/CI. The official image honors the same `MYSQL_DATABASE` /
`MYSQL_USER` / `MYSQL_PASSWORD` / `MYSQL_ROOT_PASSWORD` env contract, so
the rest of the blueprint is unchanged.
`8.0.44` (latest 8.0) was chosen over `8.4` so existing deployments
upgrade in place from their current 8.0.24 data volume without a
cross-major manual step.
# Checklist for submitter
- [x] Changes file added for user-visible changes in `changes/`.
## Testing
- [x] QA'd all new/changed functionality manually
Verified locally (Docker) that the failing query shape behaves as
expected across versions:
| Query shape | MySQL 8.0.24 | MySQL 8.0.44 |
|---|---|---|
| `SELECT 1 UNION (SELECT 2)` | works | works |
| `SELECT 1 UNION (SELECT 2 UNION SELECT 3)` | **ERROR 1235** | works |
| `(SELECT 1 UNION SELECT 2) UNION (SELECT 3 UNION SELECT 4)` | **ERROR
1235** | works |
`docker-compose.yml` already runs `mysql:8.0.44` with the same env
contract, so the image swap is a drop-in. Remaining validation on a real
Render Blueprint instance: fresh provision health (`/healthz`, `fleet
prepare db`, `hostport` resolution) and in-place upgrade from an
existing 8.0.24 volume.
<!-- This is an auto-generated comment: release notes by coderabbit.ai
-->
## Summary by CodeRabbit
* **Bug Fixes**
* Updated the database deployment target to a newer MySQL version,
resolving a Render deployment error related to union nesting.
* Switched the managed database service to use an explicit MySQL 8.0.44
image for more reliable deployments.
<!-- end of auto-generated comment: release notes by coderabbit.ai -->
---------
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
If a "plan" is not defined, render will default to its "starter"
instance type. For MySQL this means an instance with 0.5 CPU and 512MBs
of RAM. In my testing with only a few hosts enrolled, this resulted in
the service regularly running out of memory and needing to restart.
Bumping this up to a "standard" instance type with 1 CPU and 2 GBs of
RAM has shown to be more stable.
Redis continues to operate without issue on the "starter" instance type
but included defining this in the yaml so it can be updated in the
future if needed.
Leon Xu