> ## 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.

# Cloud Installation

> Use Wirekite on infrastructure we host and operate.

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):

1. **Your customer URL** — `https://<your-id>.cloud.wirekite.io`
2. **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.

<Warning>
  The root user can only be created once. Store these credentials securely —
  there is no out-of-band password reset for the root account.
</Warning>

### Step 3: Configure your first migration

After signing in:

1. **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.
2. **Add a target** — pick a target type (Firebolt, Snowflake, BigQuery,
   Spanner, etc.) and enter its credentials.
3. **Create a migration** — choose source + target, pick the schemas and
   tables you want.
4. **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                                                                          |

Most customers either:

* 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.