> For the complete documentation index, see [llms.txt](https://docs.neova.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.neova.io/our-product/our-iaas-solution-simplifying-data-flow-and-integration.md).

# Our IaaS Solution: Simplifying Data Flow and Integration

## Neova for enterprises

Your teams want a drive they can open without a training session. Your infrastructure team wants to know who stores the bytes, who is allowed to join, and how a machine leaves the network. NeoDrive is the first. The private swarm is the second. They ship as one product.

### For the people using it

NeoDrive is a file space in the browser.

* Sign-in with email or the company SSO. No wallet rollout.
* Folders, upload, trash, restore, favorites, quotas.
* Encryption on every upload, in the browser, before the file is stored.
* Names and the tree in the index, so search, sort, and rename stay instant.

Security is the default path. People do not enable a special mode, and they do not learn a content address to do their job. The standard is the one beta users already report: it feels like the drive they know.

### For the people running it

The bytes live on a closed IPFS swarm.

* Public nodes cannot complete the handshake.
* CIDs are not published to the public DHT.
* The Private Indexer is the directory, and it returns providers in score order.
* The Swarm Accelerator reads from those providers, hedges after about 200 milliseconds, and caches hot files.
* Capacity can be Neova’s operator network, or nodes you bring yourself. Same announce, same registry, same gateway.

The application keeps speaking in folders and CIDs. It does not pin a file to “that server, that disk” in the product model. Add a healthy node and the indexer has another provider. The drive does not change.

### Two questions every security review asks

**Who can read the file?** The browser encrypts with AES-GCM before upload. A node holds ciphertext. A copy of its repository does not yield the document. The account key sits in a vault, separate from the drive database, and is released to the user’s session. Details are in Security.

**Who is allowed on the network, and where?** Swarm key v1 is the wall around the swarm today. Swarm Keys v2, the control plane from the IPFS Foundation grant, is how that wall becomes policy:

* a signed identity per node, with an expiration;
* a role: storage, gateway, accelerator, or operator;
* rotation and revocation of one node, with the rest of the swarm left running;
* a zone on the credential, for deployments that must place storage in a given region.

v2 runs as a sidecar. The IPFS node stays a standard Kubo node. Policy updates land as signed data. You do not fork the protocol to change who is welcome. The full scope is in Open-source contribution.

### How it compares

|                         | A centralized drive                   | NeoDrive on the Neova swarm                    |
| ----------------------- | ------------------------------------- | ---------------------------------------------- |
| Daily experience        | Folders, upload, download             | Folders, upload, download                      |
| Where bytes live        | The provider’s datacenter             | Nodes of a private swarm                       |
| What the host can read  | Often the file itself                 | Ciphertext. Decryption stays in the browser    |
| A slow or failed reader | The provider’s failover               | The accelerator asks the next healthy provider |
| Adding capacity         | A ticket, a region, a contract change | Another node announcing to the same indexer    |
| What you can audit      | A proprietary API                     | IPFS, HTTP, and public specifications          |

An index, a key vault, and a content registry are part of the service. They are why the product is as direct as a drive. The shift is where the bytes live, who can read them, and the fact that the protocol under them is published.

### A network for data, not only for the drive

The same private swarm hosts more than personal files. It is a place to keep data, run a database, and serve a static website. One directory, one read gateway, one admission rule. The client changes. The network does not.

Three workloads sit on it today as a storage target:

* **Data.** Exports, archives, and application blobs, addressed by CID and served through the accelerator.
* **Databases.** A copy of a database, off the primary host, on nodes you can name.
* **Static websites.** Built files published on the swarm and read back through the gateway.

NeoDrive is the first screen, because a file is easy to judge. The network underneath is what you still have when the workload is a backup, a database, or a site.

### Automatic backup, from one console

We are building the front end that makes those workloads usable without operating IPFS by hand. It generates access credentials for the swarm. A backup job uses that access and runs on its own: the data leaves the primary system and lands on the private network, on the same indexer and the same accelerator as NeoDrive.

You do not stand up a second cloud to keep a copy. You issue an access, point the backup at it, and the swarm holds the result.

The same network still takes the rest:

* **Partner capacity.** A host with spare disk joins the swarm, announces, and enters the same ranking as every other provider.
* **A regional copy.** As Swarm Keys v2 zones come into operation, an organization can require selected data to live on nodes in a chosen zone: a copy outside the primary building, on infrastructure you can name.

### Where to go next

| You want                       | Start with               |
| ------------------------------ | ------------------------ |
| The product your team will use | NeoDrive                 |
| To operate capacity            | Node operators           |
| The protocol, in public        | Open-source contribution |
| A definition in one line       | Glossary                 |

Bring the use case. A team drive, a node fleet, or a swarm of your own all start from the same stack, and the conversation is more useful when it starts from the workload.