CloudQuery CLI 6.41.0 Tightens Platform Init
CloudQuery is an open source ELT and asset inventory project for moving cloud and SaaS data into queryable stores. This week was not noisy, but it matters for teams using CloudQuery Platform: CLI 6.41.0 changes how cloudquery init creates Platform sync specs, and the Square source plugin picked up security patch releases.
Platform init now trusts Platform
The main change is the new Platform sync spec scaffold. For Platform tenants with no explicit destination, cloudquery init now asks Platform for the recommended source config and writes that config directly. The CLI no longer builds the spec from hub docs and then edits the YAML locally.
That sounds small, but it removes a real source of bad generated specs. The commit notes that the old path could inherit a GCP example with a live placeholder like project_ids: ["my-project"], which then broke syncs. The new path moves the important choices to Platform: pinned source version, auth placeholders, destination wiring, and recommended tables.
For operators, the behavioral change is the stricter failure mode. The old recommended table lookup was best effort. If it failed, init could fall back to the example config. Now the scaffold is required. If Platform returns an error or an empty config, init fails instead of producing a weak spec that looks valid until sync time.
Useful details to check when this lands in your workflow:
- Platform tenants without a destination now get a source spec wired to the injected
platformdestination - The request goes to
GET /external-syncs/recommended-source-config - Empty config is treated as an error
- Local YAML table rewriting was removed
CLI 6.41.0 is a narrow release
The CLI 6.41.0 release commit packages that Platform init work. The release notes do not show a broad CLI surface change. This is mostly about making generated Platform specs closer to what Platform itself accepts.
That is still worth testing if init is part of a bootstrap script. Anything that assumes init always writes a file may now need to handle a Platform lookup error. This is the correct kind of annoying. It fails earlier, with a clearer reason, instead of sending a generated file into a later sync failure.
The follow up dependency updates also pulled the new CLI module through the repo. The root Go module moved to CLI v6.41.0, and the staged top file list shows cli/go.mod changing during the same window. If you vendor or embed CloudQuery CLI packages, this is the commit to read before bumping.
Square plugin security patches
The Square source plugin had two release steps in the window. v1.3.32 went out, then v1.3.33 followed with dependency fixes in the Python package metadata.
The important dependency is pyarrow. CloudQuery merged a pyarrow 23.0.1 security update, and the newest commit repeats that bump in the lock file via another pyarrow security update. The advisory text in the commit body is about an Apache Arrow C++ use after free issue when reading certain IPC files with pre buffering enabled. Python bindings are called out as not exposing that exact API, but shipping the patched version is still the sane default for a data connector.
The plugin also took pytest 9.0.3 as a security update. That is test tooling, not runtime sync logic, but it keeps the plugin build chain current. The files to watch are plugins/source/square/pyproject.toml for package constraints and plugins/source/square/uv.lock for the resolved environment.
Go module refresh across destinations
The Go side of the repo was mostly dependency hygiene. CloudQuery merged multiple aws-sdk-go-v2 monorepo bumps across destination plugins, including the S3 destination update. The changed files include plugins/destination/s3/go.mod, with similar updates for GCS, BigQuery, MongoDB, Firehose, and Gremlin modules.
For users, this is not a config migration. It is still worth tracking because destination plugins sit close to auth, retries, storage APIs, and upload behavior. Small SDK shifts can matter when a cloud provider changes an edge case or response shape. The commit bodies are generated by Renovate, so the useful part is the module set and the plugin path affected.
The CLI also moved to google.golang.org/grpc v1.82.0 in the grpc update. The upstream notes mention stricter RPC path validation and future header list size behavior. Most CloudQuery users should see this as maintenance, but anyone embedding the CLI or testing unusual grpc paths should run their normal integration tests.
How to prepare
If your team uses CloudQuery Platform, rerun init in a test workspace after moving to CLI 6.41.0. The output should now reflect the Platform recommended config, not a locally rewritten hub example. Treat init failure as a real signal, especially for missing tenant config or stale Platform endpoints.
For Square source users, upgrade to the latest v1.3.33 plugin release and check that your lock file resolves pyarrow 23.0.1. The change is dependency focused, so the main risk is environment drift in Python packaging, not a new sync option.
For destination plugin maintainers, skim the Go module bumps before cutting downstream builds. The week is mostly maintenance, but the Platform init change is a real behavior change. That is the one to test before it becomes part of an automated onboarding path.