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).
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.
That’s the entire handoff. We do not send a license file in the cloud path
because the license is installed on the VM at provisioning time.
Getting started
Step 1: Open the URL
Browse to https://<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.
The root user can only be created once. Store these credentials securely —
there is no out-of-band password reset for the root account.
- 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.
The UX shows row counts, throughput, lag, and error logs in real time.
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.
Ask your Wirekite rep which option fits your network. The egress IP is
provided at hand-off.
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/data and /mnt/change mounts 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.
Getting help
The cloud path comes with hands-on operator support. For anything that doesn’t
fall into your day-to-day source/target configuration — VM sizing, network
plumbing, version upgrades, performance tuning — contact your Wirekite rep
through your account’s secure channel. 