> ## Documentation Index > Fetch the complete documentation index at: https://docs.neoagent.io/llms.txt > Use this file to discover all available pages before exploring further. # Connecting Scale Computing HyperCore to Neo > Publish a client's HyperCore REST API with a trusted certificate, give Neo a user, and save it in Neo You connect HyperCore once for each client, with three values for that client's cluster: the address of one of its nodes, and the user name and password Neo signs in with. ## Before you start * Neo works with **HyperCore 9.x**. Its REST API runs on every node of the cluster, at `https:///rest/v1/`. A few operations need **9.7.1 or later**. * Neo reaches the node over the internet. Its REST API must answer on **HTTPS** at a public address, with a certificate from a public certificate authority. HyperCore ships with a self-signed certificate, which is not enough. Do one of these: * Give the node a DNS name and install a certificate for that name from a public authority on each node, in the HyperCore web interface or with HyperCore's `Certificate` API call. Each node keeps its own certificate. * Publish the REST API through a reverse proxy that has such a certificate (below). * HyperCore has no cluster address: you save one node's address. While that node installs a HyperCore software update, its API does not answer for some minutes, and Neo's calls to it wait and fail until it is back. ### Publish only the REST API Put a reverse proxy at the network edge of the site that runs the cluster. Set it to: * answer on a public name over HTTPS, with a certificate from a public certificate authority; * forward only paths under `/rest/` to a node of the cluster, and refuse every other path; * accept connections only from [Neo's addresses](https://docs.neoagent.io/integrations/ip-whitelisting.md); * pass the `Authorization` header through unchanged. Save the proxy's public address in Neo. ## 1. Give Neo a user on the cluster **1. Create a user for Neo** In the HyperCore web interface, open **Settings → Users** and add a local user for Neo, such as `neo`, with a password of its own. **2. Give it roles** Give the user the roles your agents need: **Read** for agents that only read, **VM Power Controls** to start, reboot and shut down VMs, **VM Create/Edit** to change, clone and snapshot VMs, **VM Delete** to delete them, **Backup** for snapshots and replication, **Cluster Settings** for settings, or **Admin** for every call. Neo can do only what this user may do, whatever the agent's access profile says. > [!WARNING] > > If the user's password changes or the user is removed, Neo loses access to this client's cluster until you save the new password here. ## 2. Add the connection in Neo **1. Open Integrations** In the Neo Dashboard, open [**Integrations** → **Scale Computing HyperCore**](https://dashboard.neoagent.io/integrations?open=scale_hypercore), under Servers & Virtualization. **2. Save the node and the user** In **Customer**, choose the client this cluster belongs to; the client must be on your **Companies** tab, and **Add customer** adds the next one. Then enter the node's address (for example `https://hypercore.example.com`, or the proxy's address), the user name and the password. Click **Save settings**. Neo signs in and reads the cluster before saving, so a wrong address, a refused password or an untrusted certificate is rejected straight away. ## 3. Turn it on per agent Open the agent, go to its **Tools & Settings** tab, click **Servers & Virtualization**, and expand the **Scale Computing HyperCore** block. Pick one of its **Presets**, or set each area yourself: | Area | Covers | | - | - | | **Virtual Machines** | VMs with their vCPU, memory, disks, NICs and snapshot schedule, VM stats; create, edit, clone, import, export and delete VMs, disks and NICs | | **VM Power & Migration** | Start, shut down, power off, pause, reboot, reset and live-migrate a VM | | **Snapshots** | Snapshots and snapshot schedules, and assigning a schedule to a VM | | **Replication** | Replication to another cluster and the connections to other clusters, any snapshot or schedule that turns replication on, and any schedule change that sets replication | | **ISOs & Disk Images** | ISO records and uploaded disk images; attach an image to a VM | | **Cluster, Nodes & Tasks** | The cluster, nodes, drives, GPUs, health alerts, tasks and software updates | | **Cluster Settings & Alerts** | Cluster name, DNS, time, SMTP, alert targets, monitoring, SNMP, certificates and registration | | **Users & Sign-in** | The cluster's users, roles and OpenID Connect sign-in | Keep **Cluster, Nodes & Tasks** at least Read Only for every agent that changes something: each change runs as a task, and the agent reads the task to know it finished. | Preset | What runs on its own | What asks a technician | | - | - | - | | **Read Only** | Every read | No write is allowed | | **Helpdesk** | Every read | Snapshots and snapshot schedules, power and every other VM change. Every other area stays read only | | **IT Admin** | Every read and most writes | Cluster settings and alert targets, and users and sign-in | | **Full Automation** | Every read and write | Only the writes that always ask | The writes that always ask, whatever the preset, are listed under Safety Controls on the [Scale Computing HyperCore API](https://docs.neoagent.io/agents/tools/networking/scale-hypercore-api.md#safety-controls) page. ## Use it for a VM audit A scheduled agent with the Read Only preset can list each client's VMs with their vCPU, memory and the snapshot schedule each one has, and flag a VM with no schedule. Ask your Neo Support Agent to set one up for the clients you name. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.