Skippr Docs

Appearance

What Network Access Skippr Needs for ClickHouse ​

June 2026

ClickHouse source access is mostly about the HTTP endpoint, the right database, and a user that can actually read the tables you plan to ingest.

Short Answer ​

Skippr needs outbound access to the ClickHouse HTTP endpoint, not just general reachability to a machine that happens to run ClickHouse. The source docs are explicit that the connector uses a URL such as http://localhost:8123, plus a database, user, and password, so the useful boundary is the exact HTTP interface and database context that exposes the tables you want.

That matters in ordinary deployments. A team may be able to SSH to a host or reach another ClickHouse service port and still not have a usable Skippr source because the HTTP interface is on a different listener, behind a different load balancer, or disabled for the runner network. If the intended table is analytics.events, the path is not complete until the runner can reach the HTTP URL, authenticate as a user with read access, and read from the chosen database.

Why Teams Struggle with This ​

ClickHouse source setups usually fail at the operational edge, not in the YAML syntax. The config can look complete while the runner is pointed at the wrong interface, the default database instead of the real one, or a user that can log in but cannot read the selected tables.

  • Skippr reads ClickHouse over the documented HTTP API, so a reachable native listener is not enough.
  • The user needs read access to the selected database and tables before extraction can start.
  • Choosing the wrong database can produce a successful connection and the wrong data boundary.
  • If you use query, that SQL becomes the extraction contract and overrides table-based expectations.

How Skippr Handles It ​

Skippr keeps the ClickHouse boundary narrow on purpose: url, database, user, password, then either tables or query. That makes the network requirement easy to explain to infrastructure teams because you are asking for one outbound HTTP path to one endpoint rather than a vague allowance for database access.

The same narrowness helps with troubleshooting. When the docs say the runner must reach the ClickHouse HTTP endpoint and the user needs read access, you can test those conditions directly instead of arguing about a broad VPC policy that still leaves the wrong interface exposed.

  • Uses the ClickHouse HTTP URL as the source connection boundary.
  • Reads from an explicit database and table list, or from one custom SQL query.
  • Supports environment-variable password handling instead of inline secrets.
  • Keeps the source namespace readable as clickhouse.{database}.{table}.

What the First Useful Version Looks Like ​

The first useful version is one HTTP URL, one read-only user, one database, and one table such as events that you can validate from both ClickHouse and the landed output.

If that first table is not readable end to end, fix the endpoint or permissions first. Everything broader will fail for the same reason, only with more noise.