Beta cohort
Apply for the free 30-day cohort. No card is required and there is no automatic charge. A named technical operator and independent backup are mandatory.
◎ EN
Installation and operations
Deploy with clarity.
Not guesswork.
Limited beta documentation
Signed native Linux packages are available for guided x86-64, ARM64 and Raspberry Pi OS 64-bit pilots. Other platform instructions remain preparation guidance only.
View the free beta →Universal preparation
Decisions to make before
the first sync.
A release package will not remove the need for ownership, capacity, permission and recovery planning.Cubbit project
Prepare the approved Cubbit project and bucket design. Bucket versioning is required by the engineering plan; Object Lock is optional and must follow a reviewed retention decision.
Host access
Use a supported 64-bit host with administrator access. Final minimum CPU and RAM are not validated; plan at least 2 CPU cores, 4 GB RAM and storage capacity for the full local dataset plus working reserve.
Folders and permissions
Create the local synchronization root and a separate agent-state folder. Use a dedicated non-root identity and do not grant access to unrelated shares.
Network
Allow outbound encrypted web connections to the approved SaaSolution and Cubbit endpoints. Keep the local setup surface private; exact endpoint allow-lists will be published with the release.
Recovery point
Take and verify an independent backup before first synchronization. Synchronization and version history do not replace an immutable backup.
Authoritative location
Write down which site contains the initial authoritative data. Do not combine unrelated non-empty folders before the reconciliation workflow has reviewed them.
Platform guides
Choose the intended host.
Accessible tabs show every planned procedure and its current release boundary.Platform guide
Docker
Docker is the first intended packaging route, but no signed public image reference is available. Approved testers will receive an image reference and checksum through the early-access programme.
- 01
Install a supported Docker Engine and Compose release on a 64-bit x86 or ARM host. Final minimum versions will follow release validation.
- 02
Create a dedicated non-root service account and an Edge data directory that is separate from the synchronized business folder.
- 03
Mount the host’s approved SMB/NFS backing folder into the container. The NAS remains responsible for serving that folder to local users.
- 04
Bind the local setup port to loopback or a trusted administration network only. Never expose an unauthenticated setup surface to the public internet.
- 05
Place the beta image reference in an environment file supplied to the host administrator. Do not place Cubbit credentials or permanent node secrets in Compose.
- 06
Start the container, open the local setup address shown in its logs and complete the short-lived pairing flow.
- 07
Select the local synchronization root, run validation and start the first synchronization only after confirming which location is authoritative.
- 08
Verify health, journal status, available disk reserve and a small test file before enabling production access at a new location.
- 09
For an update, pause the node, verify the signed release reference, pull the approved image and recreate the container without deleting the Edge data volume.
- 10
For a safe uninstall, pause and revoke the node, confirm all pending operations are resolved, remove the container and retain data until recovery requirements are confirmed.
Release boundaryThe Compose pattern below intentionally requires an image reference supplied to approved testers. It is not a public download link.
Request platform access ↗Platform guide
Synology DSM
No DSM version or Synology package has been validated. These steps describe the planned Container Manager route and must not be treated as production support.
- 01
Wait for SaaSolution to publish the tested DSM and Container Manager version matrix.
- 02
Install Container Manager from Synology Package Center after checking the model’s architecture.
- 03
Create or select a shared folder and preserve a verified backup before first synchronization.
- 04
Grant the dedicated container account access only to the approved share and a separate Edge data folder.
- 05
Deploy the signed Edge container image supplied through the approved release channel.
- 06
Pair the node with a short-lived code and assign the approved Cubbit-backed folder.
- 07
Configure SMB or NFS through DSM File Services; Edge does not replace Synology’s native sharing controls.
- 08
Validate health, storage reserve, pending operations and a small test file.
- 09
Use Container Manager to update only after pausing the node; keep the data volume during recreation.
- 10
Before removal, revoke the node and verify that other sites hold the expected files and version history.
Platform guide
QNAP QTS/QuTS
No QTS or QuTS hero version has been validated and no Container Station template has been released.
- 01
Wait for a published QTS/QuTS and Container Station compatibility matrix.
- 02
Install Container Station and confirm whether the NAS uses x86-64 or ARM64.
- 03
Create or select the operational shared folder and take a verified backup.
- 04
Grant a dedicated non-root container account the minimum required folder permissions.
- 05
Deploy only the signed image reference supplied by SaaSolution early access.
- 06
Pair the node, select the assigned Cubbit folder and confirm the local root.
- 07
Configure SMB or NFS through QNAP’s native sharing controls.
- 08
Validate the node and a small test file before enabling the share for users.
- 09
Pause before image updates and preserve the Edge data volume.
- 10
Revoke and drain the node before safe removal.
Platform guide
TrueNAS SCALE
No TrueNAS SCALE release has been validated and no application chart is available.
- 01
Wait for the published TrueNAS SCALE compatibility statement.
- 02
Create separate datasets for operational files and Edge state, with a verified snapshot or backup.
- 03
Set the service identity and ACLs before container deployment.
- 04
Deploy the future signed container using the documented application or custom-app route.
- 05
Map the operational dataset and Edge state dataset to their documented container paths.
- 06
Pair the node and assign the organization and folder scope.
- 07
Configure the SMB share with TrueNAS native sharing controls only after initialization.
- 08
Validate health, permissions and a small end-to-end file update.
- 09
Pause and snapshot state before updates; retain datasets during app recreation.
- 10
Revoke the node and confirm retention requirements before removing datasets.
Platform guide
Unraid
No Community Applications template or supported manual container definition has been released.
- 01
Wait for the signed Community Applications template or approved manual container instructions.
- 02
Create or select an Unraid share and verify its backup before synchronization.
- 03
Create a separate persistent path for Edge state and restrict both mappings to a dedicated identity.
- 04
Map the share to the documented container root without broad access to unrelated shares.
- 05
Deploy the approved multi-architecture image and keep the setup port private.
- 06
Pair the node and choose the assigned organization folder.
- 07
Validate permissions, disk reserve and a small test file.
- 08
Pause the node before updates and preserve its state mapping.
- 09
Revoke and drain the node before container removal.
Platform guide
Raspberry Pi
The signed Linux ARM64 beta can be evaluated on Raspberry Pi OS 64-bit with a Raspberry Pi 4 or later and reliable external storage.
- 01
Use a Raspberry Pi 4 or later with 64-bit Raspberry Pi OS and download the signed ARM64 beta archive.
- 02
Use an external SSD for business files and Edge state. A microSD card should not be the primary business file store because of endurance and recovery risk.
- 03
Mount the SSD persistently and verify a separate backup before initialization.
- 04
Verify SHA256SUMS and its Ed25519 signature before extracting the archive.
- 05
Install the native ARM64 binaries with a dedicated non-login service identity.
- 06
Complete the beta setup with the node-scoped values supplied during onboarding.
- 07
For a generic appliance configuration, publish the folder with Samba only after the initial dataset is validated.
- 08
Check thermal stability, storage reserve and a small file transfer before production use.
- 09
Pause and verify the signed ARM64 release before updates; preserve the state volume.
- 10
Revoke the node before removal and keep the SSD until retention needs are confirmed.
Platform guide
Generic Linux
Signed native beta archives are available for Linux x86-64 and ARM64. They are intended for guided, non-production pilots with an independent backup.
- 01
Download the signed archive matching Linux x86-64 or ARM64 from the beta page.
- 02
Verify the release signature and archive SHA-256 before extracting it.
- 03
Create a dedicated service user and group with minimum access to the approved folder.
- 04
Keep agent state on a separate persistent filesystem path with sufficient reserve space.
- 05
Integrate with an existing Samba or NFS service; Edge does not need to replace it.
- 06
Run the beta setup tool using the node-scoped values provided during onboarding; never pass secret keys as command arguments.
- 07
Validate the path, storage reserve, outbound connectivity and a small test file.
- 08
Pause and drain before upgrades, then verify the signed package or image.
- 09
Revoke the node before removal and retain state until recovery is confirmed.
Platform guide
Windows Server
The repository contains a separate Windows desktop backup preview, not a supported Windows Server Edge service. Installation instructions would be misleading, so no download or command is published.
- 01
Do not install the Windows desktop preview as an Edge server service.
- 02
Join the platform notification list if Windows Server is required for your environment.
- 03
Share the Windows Server version, filesystem, architecture and expected folder scale with SaaSolution for planning.
- 04
Continue using an independent verified backup while the platform is unsupported.
Release boundaryWindows Server remains not yet supported and untested for Edge. Contact SaaSolution for deployment planning.
Request platform access ↗Docker Compose pattern
No hidden credentials.
The image value is deliberately required from an approved release. Pairing happens after startup, through the local setup flow.
compose.yaml
services:
edge:
image: ${SAASOLUTION_EDGE_IMAGE:?Supplied to approved beta participants}
restart: unless-stopped
user: "${EDGE_UID:-1000}:${EDGE_GID:-1000}"
volumes:
- ./edge-data:/var/lib/saasolution-edge
- /srv/company-share:/data/company
ports:
- "127.0.0.1:${EDGE_SETUP_PORT:-8090}:8090"
environment:
EDGE_CONFIG: /var/lib/saasolution-edge/config.jsonAfter receiving the approved image reference
docker compose pull && docker compose up -dSecure beta onboarding
Pair the node.
Keep secrets out of scripts.
Beta onboarding is manually approved. The setup tool generates encryption and management secrets locally and refuses to overwrite an existing installation.- 01
Sign in to SaaSolution Drive.
- 02
Open Admin → Edge Nodes.
- 03
Select Add Edge Node.
- 04
Enter the location and node name.
- 05
Generate a short-lived pairing code.
- 06
Enter the pairing code in the local setup page or installer.
- 07
Select the assigned Cubbit bucket and allowed folders.
- 08
Confirm the local storage path.
- 09
Run the validation checks.
- 10
Start the initial synchronization.
Pairing codes expire.
Permanent secrets must not be pasted into installation commands.
Each node gets its own revocable identity.
Removing one node does not remove files from other locations.
First-site and second-site rollout
Establish one source.
Then add the next location.
Initialization is a controlled migration step, not a shortcut for merging two unrelated folders.Initial authoritative copy
Location A
- Install and pair the first Edge node.
- Select the initial local source folder.
- Mark it as the initial authoritative copy.
- Complete the first Cubbit synchronization.
- Confirm that the node is healthy.
Validated destination
Location B
- Install the second Edge node and pair it to the same organization.
- Assign the same shared folder.
- Start with an empty destination unless migration tooling explicitly supports otherwise.
- Download and validate the initial dataset.
- Enable SMB/NFS only after initialization, then test a small file.
Do not combine two unrelated, non-empty folders. First allow the initial reconciliation process to inventory and review both sides. Otherwise duplicate names, case collisions, stale deletions and unrelated histories can create unsafe results.
Day-to-day management
One operational view
for every node.
The administration runtime remains an external release gate, so this section documents the intended controls rather than pretending they are live.Node status and online/offline indicators
Last successful sync and pending files
Bandwidth controls and synchronization schedules
Selective folders and low-storage alerts
Conflict inbox and version restoration
Pause, resume and revoke a node
Replace failed NAS hardware
Re-enroll a recovered location
Replacing failed hardware
Revoke or pause the old node, restore the operating system and local storage from a verified recovery source, enroll the replacement as a new node identity, validate the dataset before publishing SMB/NFS and only then retire retained recovery material.
Troubleshooting
Search the symptom.
Protect the secrets.
Never post secrets, access keys, encryption keys or recovery codes in a support request.16 guidance entries
Node appears offline+
Confirm local power and LAN access, then check outbound HTTPS connectivity and the privacy-safe health report. Local file access should remain available.
Pairing code expired+
Generate a new short-lived pairing code in Admin → Edge Nodes. Never reuse an expired code or paste a permanent secret into a command.
Cubbit credentials rejected+
Confirm the assigned project and bucket permissions. Do not send access keys, encryption keys or recovery codes to support.
Folder permissions incorrect+
Verify that the dedicated non-root Edge account can read, create, rename and delete a test file inside only the approved synchronization root.
Files remain pending+
Check the node journal, schedule, bandwidth limit, remote availability and whether a safety pause is active. Pending items should not be deleted.
Not enough disk space+
Free space on both the operational volume and the Edge data volume. The agent keeps a reserve before applying downloaded files.
Filename case collision+
Rename one of the colliding items. Case-insensitive systems can map two distinct remote names to the same local path, so materialization is intentionally blocked.
Unsupported filename+
Remove reserved characters or names for the destination platform, then allow the journal to retry the operation.
Conflict requires attention+
Open the conflict inbox, compare both retained versions and choose Keep A, Keep B, Keep both or download both for comparison.
Upload interrupted+
Restore connectivity and allow the idempotent journal operation to retry. Do not clear the Edge data directory.
Initial synchronization incomplete+
Keep the share disabled for users at a new destination until validation finishes. Check storage capacity, permissions and the pending-file count.
SMB/NFS share unavailable+
Check the NAS native file service separately from Edge. Edge synchronizes the host folder but does not replace the NAS file-sharing service.
Container does not start+
Inspect the health output for a missing image reference, architecture mismatch, read-only volume or non-root permission problem.
ARM64 image unavailable+
ARM64 is planned but no public image is available. Request early access and do not substitute an unverified third-party image.
Clock or timezone warning+
Enable reliable time synchronization on the host. Logical revisions protect causality, but accurate time keeps audits understandable.
Collect a privacy-safe diagnostic bundle+
Use the future diagnostics command to collect allow-listed health and configuration metadata. Review it before sharing and exclude secrets, keys, file contents and filenames.
Need help planning the first deployment?