In the cloud path, Wirekite runs on a dedicated VM that we provision, operate, and patch on your behalf. There is nothing to install on your side — you receive a URL and a license, sign in, and start configuring migrations. The cloud deployment is functionally identical to on-prem and Docker: same UI, same source/target support, same caps and metering. The only differences are operational (we own the host) and license validation (MAC address and clock checks are skipped, since cloned VMs cannot have stable MACs).Documentation Index
Fetch the complete documentation index at: https://docs.wirekite.io/llms.txt
Use this file to discover all available pages before exploring further.
What you receive from Wirekite
Two things, delivered out-of-band (signed URL, secure email, or portal):- Your customer URL —
https://<your-id>.cloud.wirekite.io - First-login instructions — confirmation that the URL is live and a one-line note that you’ll be prompted to create a root user on first browse.
Getting started
Step 1: Open the URL
Browse tohttps://<your-id>.cloud.wirekite.io. The cloud edge terminates
TLS with a Let’s Encrypt wildcard certificate, so your browser will not
show a certificate warning.
Step 2: Create the root user
The first person to reach the URL is prompted to create the root user (username + password). This account is the only administrator until you create additional users from inside the app.Step 3: Configure your first migration
After signing in:- Add a source — pick a database type (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB), enter host/port/credentials. Wirekite tests the connection and stores credentials encrypted on the data disk.
- Add a target — pick a target type (Firebolt, Snowflake, BigQuery, Spanner, etc.) and enter its credentials.
- Create a migration — choose source + target, pick the schemas and tables you want.
- Run — Wirekite extracts the schema, applies it to the target, streams data, and (optionally) starts continuous CDC replication.
Network requirements
For Wirekite to reach your source and target databases, the cloud VM needs outbound network connectivity to the host:port of each database you configure.| Direction | Endpoint | Why |
|---|---|---|
| Outbound from VM | Your source DB | Schema extraction + initial-load reads + CDC reads |
| Outbound from VM | Your target DB | Schema apply + bulk writes (or staging bucket for Snowflake / BigQuery / Firebolt) |
Inbound to <your-id>.cloud.wirekite.io:443 | Your browsers | UI access |
- Allow-list the cloud VM’s outbound egress IP at their database firewall, or
- Run a private-link / VPN tunnel between their VPC and ours.
Operational responsibilities
| What | Who owns it |
|---|---|
| VM patching, OS updates | Wirekite |
| Wirekite version upgrades | Wirekite (coordinated with you) |
| Source/target DB credentials | You |
| Schema/migration design | You |
| Source/target firewall rules | You |
Backup of encryption.key | Wirekite (per-customer, in operator vault) |
| Backup of source/target databases | You |
Limits compared to on-prem and Docker
A few cloud-specific differences worth knowing:- API server is disabled. The cloud path is UX-only. If you need
programmatic access, ask about on-prem or Docker with
--with-api. - Per-migration data/change directories are hidden in the UI; cloud uses
fixed
/mnt/dataand/mnt/changemounts on dedicated disks we provision. - In-place version upgrades are not yet supported. Major upgrades are done by re-provisioning your VM; we coordinate with you ahead of time and preserve all migration history.
