Take Back Your Cloud: The Complete Self-Hosting Guide,
For Home & Business
Part 1 of 2: Choose, Design & Build Your Services
By Pacific Northwest Computers | Updated November 12, 2026
Who This Guide Is For: Home users, families, small businesses, IT professionals, and home-lab enthusiasts who want to understand what they can run themselves instead of relying entirely on software-as-a-service (SaaS). Start with Part 1, even if you have nothing to migrate. Part 2 is a separate, practical migration and disaster-recovery playbook.
A Crucial Distinction: Self-hosting gives you more control, not automatic security, reliability, privacy, or savings. You become responsible for patching, backup, availability, incident response, and recovery. A hybrid design—with private files on your own NAS and public email on an appropriately hosted server, for example—is often the best compromise.
What You'll Learn
Part 1: Choose, Design & Build Your Services explains the SaaS alternatives, NAS appliances, TrueNAS, Linux, Proxmox, VPSs, network access, domain/DNS setup, website publishing, Nextcloud, business email, storage design, monitoring, real operating costs, licensing, and failure-resistant architectures. It includes concrete build recipes for homes and offices, plus more advanced Caddy, Cloudflare, ZFS, and WireGuard/Headscale topics.
Part 2: Migrate, Verify & Recover covers inventories and exports; moving files from Google Drive, OneDrive, or Dropbox; shifting an archive to TrueNAS; migrating a website or Nextcloud installation; moving a mail domain; testing every cutover; reversing a failed migration; protecting backups; and retiring the old subscription safely.
Related Pacific Northwest Computers Articles:
Best Value NAS System: Turn-Key & Custom Built — a comparison of a QNAP TS-464 appliance with a Fractal Design Node 304 custom NAS build. Prices and component choices in that May 2025 article are historical, not a current quote.
Deploy Nextcloud on TrueNAS SCALE; Behind NPMplus SSL Proxy — an installation path using the TrueNAS app system and NPMplus.
Offline AI LLM System (TrueNAS Hosted) — another example of hosting applications and persistent data locally, in this case Ollama and AnythingLLM. Follow the current TrueNAS documentation for your particular release because app management changed across versions.
Part 1: Choose, Design & Build Your Services
1. What Self-Hosting Actually Means
Most people already use services that run on somebody else's computers: Google Drive and OneDrive for files, Dropbox for sync, hosted email for communication, website builders for publishing, and cloud platforms for backups. Each service brings convenience, but also recurring charges, feature limits, provider dependencies, changing terms, and a reliance on a third party's availability.
Self-hosting means running the application—or at least its primary data and infrastructure—on equipment or virtual servers you administer. That equipment could be a small NAS under a desk, a Raspberry Pi for low-demand services, a refurbished mini PC, an old workstation, a dedicated server in an office, a cluster of Proxmox hosts, or a rented VPS in a data center. A rented VPS is still self-managed hosting, even though you do not own its physical hardware.
There are three broad operating models:
For many households and small businesses, hybrid is the sensible starting point. Own the data that benefits from local speed and control. Keep services with demanding public availability—especially mail—on infrastructure designed for that job. You can move individual components later.
What Self-Hosting Does Not Automatically Replace
A self-hosted email server does not magically provide Microsoft Word, Teams, shared calendars, or every Google Workspace feature. An SMB folder is not equivalent to Google Docs. A WordPress website export may leave booking forms, payments, search, and newsletters behind. A mirror of two hard drives is not a backup. A DNS record pointing at your home server is not a security design.
Make a service inventory first, identifying the human task being solved rather than the product being replaced. If a family only needs shared photos, deploying a complete office collaboration suite may be unnecessary. If an office needs simultaneous document editing, a mapped network drive may be insufficient.
2. Which SaaS Services Can You Replace?
Selection rule: Choose an application because it meets the users' needs. Choose the hardware only after that. A two-bay NAS may be excellent for household files and a poor fit for several heavy databases, browser editing, and mail service running concurrently.
3. Choose Where Everything Runs
A NAS is optimized for storing and serving data. A hypervisor such as Proxmox provides isolated guests. A server OS such as Ubuntu runs applications. These roles can overlap, but they are not interchangeable. A TrueNAS VM inside Proxmox can be valid with proper physical disk or HBA passthrough and a carefully designed boot/storage path, but avoid a circular dependency in which the hypervisor's own essential datastore is hosted by a guest that must start from that datastore.
Three Reference Architectures
Architecture A — Simple Household Files
Internet ── Home router/firewall ── LAN switch ── Synology or QNAP NAS
│ ├─ Mirrored disks
└─ Private VPN access ├─ Local snapshots
└─ Encrypted offsite backup
UPS protects the router, switch and NAS long enough for safe shutdown.
Architecture B — Small Office With Public Services Separated
Employees / Remote Users ── VPN ── Office firewall ── TrueNAS archive
├─ SMB shares and ACLs
├─ Local snapshots
└─ Offsite encrypted backup
Public visitors ── DNS ── Website VPS / reverse proxy
Email senders ── DNS MX ── Mail-capable VPS / email service
Architecture C — Multi-Service Proxmox/Home Lab
Internet ── Router/firewall ── VLAN-aware switch ── Proxmox host
│ ├─ VM: Caddy/public web
│ ├─ VM: Nextcloud AIO
│ ├─ VM: monitoring
│ └─ Other isolated guests
└─ Dedicated NAS / backup server
└─ Independent offsite backup
In all three, keep storage management, hypervisor control panels, backup administration, and database ports off the public internet. Use a restricted management LAN or VPN, and make sure an outage of one essential box does not disable the only backup and the only recovery instructions.
4. Plan the Service Levels Before Buying Equipment
Before ordering hardware, record:
Live data size: How many GB or TB exist today, and how fast do they grow?
Activity: How many simultaneous users; what is the largest normal file or database; do users co-edit documents?
Access: LAN only, remote staff, mobile users, or public visitors? Is offsite access needed when the building is dark?
RPO — Recovery Point Objective: Maximum data loss you can tolerate. If RPO is one hour, a single nightly backup is not sufficient.
RTO — Recovery Time Objective: Maximum acceptable outage. If staff need a record within two hours, a 20-hour full cloud restore will not meet that goal.
Security: Personal data, business confidentiality, legal retention obligations, MFA, audit requirements, and access revocation.
Operations: Who replaces a drive, responds to alarms, pays for offsite copies, and tests restoration?
The RPO/RTO distinction is central. An archive that changes once a month can tolerate a relaxed backup schedule but may still require quick read access. A busy booking database may need frequent consistent backups, but could have an acceptable multi-hour maintenance window. The correct solution depends on both dimensions.
Calculate Capacity With Room to Grow
Suppose a household has 1.2 TB of files and adds 0.2 TB/year. After three years, that's about 1.8 TB. Allow 0.5 TB for local versions and leave 20% of usable capacity free:
(1.8 TB + 0.5 TB) / 0.80 = 2.875 TB usable capacity target
Two 4 TB drives in a mirror offer approximately 4 TB decimal nominal usable capacity (about 3.64 TiB as many operating systems display it), minus filesystem, metadata, reservation, and other overhead. The separate offsite backup needs its own capacity allowance, often greater than live storage because it retains prior versions.
For a 700 GB office archive, calculate how much new work is expected, whether records are compressed or already encrypted, how long old versions must remain available, and whether the restore target must have space to hold both the old and recovered copies during a test.
Buy Components as a Complete System
UPS setup matters: Connect its shutdown-data cable or supported network signaling, configure low-battery actions, confirm events appear in the log, and carry out a controlled manufacturer-approved test. A UPS that supplies power but never tells the NAS to shut down may still leave a filesystem vulnerable when the battery finally runs out.
5. The Real Cost of Self-Hosting
There are capital expenses (CapEx)—NAS, drives, RAM, UPS, networking, and spares—and operating expenses (OpEx)—electricity, cloud backup, VPS charges, domains, replacement reserves, licensing, and maintenance. Human time belongs in the calculation for a business, whether performed by staff or a contractor.
Electricity Matters — Especially in the Pacific Northwest
Electricity costs vary by utility and rate class. As checked for this guide, Clark Public Utilities lists a residential energy charge of 8.79¢/kWh and a $19/month basic service charge. The energy component is useful for estimating the incremental cost of an always-on server already attached to that residential account. Do not add the fixed $19 to each new machine; it normally exists whether that machine runs or not. Businesses should use their own applicable tariff, which may differ.
Annual energy (kWh) = Average wall watts × 8,760 ÷ 1,000
Annual power cost = Annual energy × Your actual marginal $/kWh
30-day energy (kWh) = Average wall watts × 24 × 30 ÷ 1,000
The $0.15 and $0.20 columns are comparison assumptions, not quotes for a particular city or utility. Measure true average watts at the wall, including the drives and always-on network gear, rather than assuming the power supply's rated wattage equals continuous usage. Add cooling, battery inefficiency, and HVAC impact for dense equipment or warm rooms. Heat-pump or EV charging economics are separate household decisions; they should not be presented as a guaranteed server-cost saving.
Sample 36-Month Budgets
These are illustrative US-dollar planning scenarios, not current hardware quotes. They assume existing broadband, a three-year comparison period, and $0.15/kWh, with power measured at the wall.
The home example averages $28.90/month before assigning a cash value to household maintenance. The business example averages $280.88/month including its modeled labor, or about $28.09 per user/month for ten users. This excludes initial setup, migration labor, taxes, hot standby equipment, extra ISP charges, relay fees, paid support, emergency work, and more extensive cybersecurity measures.
Storage prices change. Backblaze B2's published standard price currently starts at $6.95/TB per 30 days, subject to its billing rules and any applicable retrieval/usage terms. One TB of live data can require more than one TB of stored backups when versions are retained.
Compare identical services. If ten staff members can truly cancel $18/user/month of subscriptions, that saves $180/month. Against the modeled $280.88/month operating expense, hosting everything yourself costs about $100.88/month more in this particular example. It may still be justified by data control, local speed, customization, or retention policy. If the office still needs a paid word processor or conferencing suite, do not count that retained subscription as a saving.
Licensing is not the only cost: A no-cost software license does not include your time, a tested disaster recovery system, an on-call technician, or a guaranteed replacement drive.
6. Software Licenses, Subscriptions & Support
Open-source software is frequently available without a per-user subscription, but the license attached to each component still matters for organizations that distribute software, customize it, or bundle it into commercial products. Review the license for the exact version and bundled dependencies.
For a business, establish who supports hardware, OS/hypervisor, applications, network, backups, and security. A vendor subscription is not an operational plan unless someone owns the response process. Check all licensing prices before publication or purchasing; currencies, included features and tiers may change.
7. Networking: LAN, DNS, Public IPs & CGNAT
Remote access and public websites are where otherwise straightforward home-server plans often fail. Your server may be perfectly functional on 192.168.x.x and unreachable to the rest of the world.
Understand the Path
Remote phone or browser
↓
Domain's DNS records (example.org)
↓
Public IP or trusted public gateway
↓
ISP / modem / firewall / router
↓
Reverse proxy or private VPN
↓
Application on NAS, Linux VM, or server
The pieces have different jobs:
Local IP address: An address only useful within your LAN or VPN. Reserve stable addresses for infrastructure or use reliable internal DNS.
Public IPv4 / IPv6 address: An address routable from the internet; may be fixed, dynamic, shared, filtered or absent.
DNS: Turns a name such as cloud.example.org into the appropriate endpoint. Domain ownership is not the same as server hosting.
Dynamic DNS (DDNS): Updates public address records if your ISP changes your IP. It does not remove an ISP's inbound filtering or CGNAT.
Port forwarding: Permits specific incoming connections through a router to an internal system, if your ISP makes inbound connections possible.
Reverse proxy: Accepts HTTP(S), commonly handles TLS, and routes different hostnames to internal applications.
VPN / overlay network: Lets authorized remote devices reach private resources without publishing every app to the internet.
What Is CGNAT?
Carrier-Grade NAT shares IPv4 addresses across customers. If your router's WAN IPv4 is in 100.64.0.0/10 or another non-public range—and does not match the public IP reported externally—you may be behind CGNAT or double NAT. A routine inbound IPv4 port-forward will not work through upstream CGNAT. Check with your ISP before assuming it is definitely CGNAT: upstream routers and modem configurations can also cause address mismatches.
Workable alternatives are:
Ask for a genuine publicly routable address or business service, if available.
Use native IPv6 with correctly configured firewall rules only if both endpoint and clients can reach it.
Deploy WireGuard, Tailscale, or Headscale for private access; relays may be necessary.
Use an outbound tunnel or a publicly addressed VPS as the web gateway, evaluating provider terms, limits and availability.
Do not blindly expose ports because a tutorial says to. Public websites need deliberate ingress. Admin consoles, SMB (TCP 445), SSH, database ports, NAS setup pages, and Proxmox interfaces should not be casually forwarded to the internet.
Email Port 25 Is a Special Case
Public email delivery between mail servers commonly uses TCP 25. Client submission uses authenticated TCP 587 (or 465 for implicit TLS). Opening 587 for your laptop does not make your server able to receive internet mail from unrelated domains.
Residential ISPs commonly block outbound TCP 25 or impose other limitations. Xfinity documents its residential port-25 submission restrictions, and its dynamic residential address space may have a poor reputation for direct sending. ISP policies differ by product, area and account type. A residential customer should test the actual line and ask the provider, not assume that all inbound and outbound directions are treated identically.
For reliable domain mail, choose a mail-capable VPS or supported hosted email endpoint with stable addressing, correctly configured PTR/reverse DNS, and demonstrably permitted mail traffic. If outbound delivery is blocked or reputation is poor, use a trusted authenticated outbound SMTP relay. If inbound TCP 25 is unavailable, use a mail host or properly configured inbound gateway that can receive it. Never describe a generic web tunnel as a substitute for working SMTP transport.
8. Choose a Safe Remote-Access Strategy
WireGuard, Tailscale & Headscale in Practice
WireGuard is an encrypted tunneling protocol. Tailscale uses WireGuard connections plus coordination and NAT traversal to simplify connecting devices. Headscale is an alternative self-hosted coordination implementation for compatible Tailscale clients; it is not automatically a drop-in substitute for every hosted Tailscale feature.
A mesh connection may be direct or relayed. Direct UDP paths are normally faster. Relays such as DERP preserve encrypted connectivity when direct paths are unavailable, but throughput and latency depend on network conditions and relay placement. Do not rely on a universal Mbps figure: test your actual path with file transfer and latency measurements. Some Tailscale configurations also support peer relays. Tailscale's connection-types documentation describes the distinction.
For home use, put the NAS behind a private VPN rather than opening its admin UI. For an office, document which users can reach which subnets. Require MFA where supported, enforce device approval or access controls, revoke former staff, and test remote access over actual cellular data. A VPN does not fix weak passwords or a vulnerable service inside the tunnel.
Headscale resilience warning: If you self-host the control server and your only relay at the same house, losing that connection can disrupt enrollment, path discovery, and relayed connectivity. Existing direct encrypted tunnels may continue for a period, but you should never promise uninterrupted operation through a control-plane outage. Place critical coordination or relay resources at a separate reachable site when warranted.
9. Secure Publishing: Reverse Proxies, HTTPS & DNS Challenges
A reverse proxy allows one public web endpoint to serve multiple services by hostname:
https://www.example.org ─┐
https://cloud.example.org ──┼── Caddy or NPMplus ─┬─ Website VM
https://status.example.org ┘ ├─ Nextcloud VM
└─ Monitoring VM
Caddy is a straightforward option for static websites and reverse proxying, with built-in automatic HTTPS when public domain validation succeeds. NPMplus is an alternative front end for Nginx-based reverse proxy management and is the approach used in our Nextcloud on TrueNAS article. Do not run multiple competing services on the same public port 443 without deliberately choosing which one owns ingress.
Example: A Static Site With Caddy
Install Caddy from the official installation instructions for your supported Linux distribution, publish site assets in /srv/www/site, and give the Caddy process read access. For a valid public hostname with inbound 80/443 and normal DNS, the site block can be very small:
www.example.org {
root * /srv/www/site
encode zstd gzip
file_server
}
Then validate and reload on a standard systemd-based installation:
sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy
curl -I https://www.example.org/
The example name is a placeholder. You still need a valid A/AAAA record, routing, firewall access, and the files. If your public server is on a VPS, point the address there. If your site is at home under CGNAT, you need an appropriate alternative public gateway.
DNS-01 TLS Certificates & Cloudflare
The ACME DNS-01 challenge proves domain ownership by temporarily publishing a DNS TXT record. It is especially useful when ports 80/443 cannot be reached for HTTP validation, or when requesting a wildcard certificate such as *.example.org. DNS-01 proves control of the name; it does not make the service reachable. A wildcard certificate can reduce the number of individual hostnames that appear in public Certificate Transparency records, but the certificate and its parent domain are not private.
The standard Caddy binary does not include every third-party DNS provider. A Cloudflare-enabled build may be made with xcaddy and the Cloudflare DNS module:
xcaddy build --with github.com/caddy-dns/cloudflare
Optional container build example:
FROM caddy:2-builder AS builder
RUN xcaddy build --with github.com/caddy-dns/cloudflare
FROM caddy:2
COPY --from=builder /usr/bin/caddy /usr/bin/caddy
For Cloudflare, use a zone-scoped API token, not a global API key, with the permissions documented by the provider module (currently Zone.Zone:Read and Zone.DNS:Edit for the selected zone). Store it in the service's secret/environment configuration, outside the website source repository. Limit who can read it and rotate if exposed.
Illustrative Caddyfile using the DNS module:
cloud.example.org {
tls {
dns cloudflare {env.CLOUDFLARE_API_TOKEN}
}
reverse_proxy 10.20.30.40:11000
}
10.20.30.40:11000 is an example backend, not a Nextcloud universal default. For Nextcloud AIO, follow its officially supported reverse-proxy configuration and choose the actual Apache backend address and binding; for the TrueNAS app, use its published service endpoint. If an upstream app expects forwarded HTTPS or host headers, configure it by its supported proxy instructions.
For systemd, a protected secret file can be loaded through a service override instead of placing the token in the Caddyfile. Restrict access to the file and to service diagnostics, and avoid printing the token in logs. A service environment variable is more appropriate than embedding a secret in published configuration, but is not an impenetrable secret store—privileged users and some diagnostics can still read process environments.
Cloudflare Upload Limits & Nextcloud
Cloudflare's proxied HTTP upload cap depends on plan. Its 413 documentation currently gives 100 MB for Free and Pro, 200 MB for Business, and up to 5 GB for Enterprise (configuration may reduce the allowed size). A large browser upload sent as one HTTP request may fail with 413 Payload Too Large even when the backend accepts large files.
Nextcloud supports application-level chunked uploads. This is not simply HTTP transfer-encoding; the client sends smaller pieces that Nextcloud can assemble and commit. Its documented files.chunked_upload.max_size default is 100 MiB (104,857,600 bytes), larger than a nominal 100 MB decimal upload cap. Where the client uses this server setting and your deployment requires a lower threshold, configure a cautious limit, such as 90 MiB, then validate on the actual client path:
# Run with the correct PHP/occ invocation and user for YOUR Nextcloud install.
# Example for a conventional Linux install using www-data:
sudo -u www-data php /var/www/nextcloud/occ \
config:system:set files.chunked_upload.max_size --type int --value 94371840
Important: AIO, app-catalog, and container distributions can have different supported occ entry points; use their documented wrapper instead of assuming the path above exists. This setting is not a guarantee for every uploader or file-sharing protocol. Check temporary storage, backend server limits, upload timeouts, and test a real multi-GB file from the intended client. A proxied large media/download workload may have other Cloudflare rules or performance implications; validate the applicable provider terms. References: Nextcloud big-file uploads and Cloudflare request limits.
10. Storage Design: Mirrors, ZFS, Snapshots & Permissions
RAID is availability against certain disk failures, not backup. In a mirror, one surviving disk normally keeps the pool accessible after the other disk fails. It does nothing by itself against accidental deletion, ransomware, theft, fire, a failed chassis, a bad update, or the loss of your encryption keys.
A robust storage plan separates:
Primary data: What users actively work with.
Local recovery points: Snapshots or versions for quick rollback.
Independent backups: Another storage device, preferably with different credentials and administrative authority.
Offsite protection: A physically separate location or trusted cloud object storage with suitable retention.
Recovery compute: A place that can actually run the service if the original server dies.
ZFS Basics
ZFS brings copy-on-write semantics, data integrity checksums, snapshots, and replication workflows. With a redundant layout, ZFS can repair many detected data errors using healthy copies. Configure periodic scrubs, SMART/drive monitoring, capacity alerts, and snapshots with a realistic retention schedule. An unhealthy vdev or critically full pool can affect the entire service; keep free space and respond quickly to errors.
For a business archive shared to Windows workstations through SMB, create a TrueNAS dataset using its SMB preset / NFSv4 ACL configuration rather than trying to force ordinary POSIX permissions into a Windows-style share. Use the TrueNAS ACL editor, named groups, least-privilege access, and inheritance settings matched to your workflow. In the current TrueNAS ACL guide, SMB shares are specifically intended to use NFSv4 ACLs. The SMB preset commonly applies Restricted ACL Mode, reducing the chance of later chmod commands unintentionally changing rich ACLs.
A Windows reader who can see but not edit closed case records should be tested as a real reader, not as an administrator with cached credentials. Remember that both share-level permissions and dataset/filesystem ACLs may affect access. SMB access-based enumeration may hide files for which a user has insufficient access, but that is not a substitute for correct ACLs. And when restoring to a different platform, verify that the backup tool preserves permissions, file ownership, timestamps, alternate streams, and ACL semantics where needed.
Database Datasets Are Different From File Datasets
PostgreSQL commonly uses 8 KiB database pages. ZFS datasets usually have a larger default maximum recordsize suited to general files. Small random database updates can create unnecessary I/O if the dataset layout is a poor match. On dedicated PostgreSQL storage, 16K is a common starting point to benchmark, not a guaranteed best setting or universal cure for write amplification:
# EXAMPLE ONLY: use the REAL dataset name BEFORE initializing a new database.
sudo zfs set recordsize=16K tank/apps/postgresql
Changing recordsize affects newly written blocks, not retroactively rewritten existing data. Database version, workload, WAL layout, memory, storage latency, compression, and sync behavior all matter. Also treat primarycache=metadata as a workload-specific experiment, not a mandatory tweak: disabling the ZFS data cache can make some workloads worse. Benchmark representative database transactions and recovery before applying production tuning. Never disable safe synchronous-write guarantees simply to make a benchmark look faster.
Encryption & Recovery Keys
Encryption protects against exposure of lost drives and some unauthorized access, but only if the keys are securely managed. Keep a separately stored recovery key or passphrase, check that a second administrator can find it during an outage, and test a restore to a different machine. Encrypted backups become worthless if their only decryption key is saved on the server that burned down.
11. Backups, Ransomware Protection & Actual Immutability
A good baseline is 3-2-1 with version history: three copies of important data, on at least two independent storage systems or media, with at least one copy offsite. For stronger ransomware protection, keep at least one offline, objectively deletion-resistant, or appropriately locked copy and verify restores (sometimes summarized as 3-2-1-1-0, with zero uncorrected restore errors).
Common Tools & What Each Does
Borg's Append-Only Mode: Helpful but Often Misunderstood
Borg can configure an SSH-accessed backup repository so a client is restricted to appending underlying repository segments. That helps limit the permanent damage an attacker can do with access to a backup client's SSH key. A representative Borg 1.x authorized_keys entry is:
command="borg serve --append-only --restrict-to-repository /srv/borg/acme",restrict ssh-ed25519 AAAA...REPLACE_WITH_REAL_PUBLIC_KEY
Use the command syntax for your installed Borg major version, verify the target repository path, secure its owner and SSH account, and test the restriction. Do not paste a placeholder public key into production. Borg's own documentation notes an important nuance: append-only forbids low-level compaction/deletion of committed segment data; borg delete or borg prune can still alter what the repository logically exposes, and reads remain possible. A compromised client may cause disruption, hide archive listings or consume disk space even if committed segment bytes have not been reclaimed.
For greater assurance, use independent backup credentials and deletion-resistant object-lock/WORM retention where available and properly configured. Keep an administrative key on a separately controlled, trusted machine for any authorized prune/compact maintenance. Audit retention and repository health periodically. Read Borg serve and Borg append-only notes for version-specific behavior.
Application-Consistent Backups Matter
A VM snapshot or raw file copy taken while a database is writing may be crash-consistent rather than application-consistent. That can be useful for rapid recovery, but should not be your sole strategy for critical data. For Nextcloud, protect its data directory, database, configuration, app settings, and encryption material at a consistent recovery point. For a CMS, back up both the SQL database and uploaded files/plugins/themes. For email, protect the mailbox stores and queue/configuration/keys. Test restoration of the working application, not merely successful extraction of files.
12. Security, Segmentation & Administrative Hygiene
Self-hosting moves the security boundary from a SaaS provider to your equipment and practices. Set these protections before inviting users:
Use unique accounts with MFA where possible; keep a dedicated administrative identity, and do not use administrator credentials for ordinary browsing or file editing.
Restrict management interfaces (Proxmox, TrueNAS, router, NAS, hypervisor, backup console) to a management VLAN or authorized VPN. Segment public web workloads from business records.
Patch deliberately. Track OS, container images, packages, applications, firmware, and security advisories. For a business, rehearse changes on a copy where practical and keep a rollback point.
Protect credentials and secrets. Store in a password manager or supported secret store; never commit real tokens to a public website repository or container image.
Use HTTPS with validated certificates for browser access and authenticated TLS for mail. Do not treat a self-signed browser warning as acceptable for production users.
Apply least privilege to application users, service accounts, storage paths, DNS API tokens, and backup destinations. Avoid reusing the same administrator password everywhere.
Review container ports. A published Docker port can be reachable even when a novice expects the host firewall alone to block it. Inspect actual listening interfaces and network paths.
Enable logging and alerting for failures, logins, capacity, certificate expiry, and backup age, without logging full secrets or sensitive file contents.
Harden remote access. Approve devices, revoke lost clients, rotate keys, and test remote access from a different network.
Protect the recovery path. The domain registrar, DNS provider, encryption keys, backup credentials, monitoring and emergency contact method should remain usable if your primary system is down.
For confidential business records, ensure the design matches any applicable contractual, regulatory, privacy, and retention requirements. A DIY installation does not automatically deliver compliance certifications, a business associate agreement, e-discovery, or a documented support SLA.
13. Build A — A Family File Cloud on Synology or QNAP
Example goal: Four household members want their own private files, a shared family folder, desktop sync, mobile access and the ability to recover an accidentally deleted document. They can tolerate roughly a day of service interruption during a total NAS replacement.
Suggested layout: One compatible two-bay NAS, two equal-capacity NAS drives in a mirrored storage pool, UPS, local snapshots where supported, and a versioned encrypted backup on separate offsite storage. Choose the actual model based on app support and future capacity. For appliance-versus-custom context, see our turn-key & custom NAS comparison.
Synology Step-by-Step
Install & initialize: Fit compatible disks, perform the supported DSM setup, install updates, and create the storage pool and volume. A mirror or equivalent protected configuration uses one disk's capacity; do not interpret two 4 TB drives as 8 TB of usable mirrored data.
Establish identities: Create a separate administrator and an everyday account for each person. Give only the permissions required for their files. Enable MFA on administrator accounts and configure an independent account-recovery method.
Create folders: Make private user folders and a shared Household folder. Set the intended reader/editor rules on that shared folder.
Enable file sync: On a compatible model, install Synology Drive Server, configure the relevant Team Folder, and connect one pilot user with Synology Drive Client. Confirm that a desktop edit synchronizes and a second user has only the expected access.
Set remote access: Begin with LAN access. For offsite access, configure a properly managed router VPN or other secure supported access method. Test from a phone with Wi-Fi off, not only from another computer in the same building. Keep SMB and DSM administration off open public port forwards.
Set protection: Configure snapshots if supported by the volume/filesystem, then a versioned backup through a supported tool such as Hyper Backup to storage independent of the NAS. Use separate credentials and secure the decryption keys.
Prove recovery: Delete a disposable test file, restore an older version to a different directory, open it, and verify the family account permissions. Document how the household would recover if the NAS itself were stolen.
Equivalent QNAP Path
On a compatible QNAP TS-464 or similar model, initialize QTS, create the desired protected storage pool, separate user accounts, and shared folders. Configure Qsync Central and Qsync Client for the folders you want synchronized. Use Hybrid Backup Sync for a backup job with usable version history, rather than assuming a two-way synchronization job is enough. Restore a test folder and test private versus shared access with normal user accounts.
Acceptance checklist: Private folder inaccessible to a second household member; shared folder syncs from two devices; phone works from cellular through approved access; important files are available offline when explicitly selected; old versions can be restored without the primary NAS.
Trade-off: The setup is approachable and relatively low power. It is still one chassis and one home connection. A public family website should live somewhere independent if downtime during a household power or ISP outage is unacceptable.
14. Build B — A Small-Business Archive on TrueNAS
Example goal: A five-person office has approximately 700 GB of closed case records, with limited future growth. Active work remains in a separate business application. The archive needs rapid local reading, controlled editing, retention, independent backups, and a credible fallback after office equipment failure.
Recommended Shape
Use a compatible dedicated TrueNAS machine with a supported separate boot device, a protected data pool using suitable drives, a UPS, and a second backup destination outside the office. A four-bay chassis may provide more flexibility than a two-bay appliance; bay count alone does not guarantee an easy future ZFS expansion path. Make the pool layout and capacity plan before buying drives.
TrueNAS Step-by-Step
Select the release & hardware: Read the TrueNAS hardware guide and choose a supported Community Edition release. Record drive serial numbers and bay positions. Install to the dedicated boot device; do not store your business pool on that same boot disk.
Create protected storage: Initialize the intended mirrored or appropriately redundant ZFS pool. Enable reporting for SMART/drive errors, pool health, temperature, free capacity, and failed scrub tasks.
Create an SMB dataset: Add a dataset such as tank/Archive using the SMB preset and its NFSv4 ACL model. Create a share such as \\archive-nas\Archive. Use stable internal DNS and a reserved server address so a replacement system can reuse the name.
Create least-privilege groups: An ArchiveReaders group should be able to open records but not modify them; an ArchiveManagers group should have controlled write access. Keep unrelated accounts out. Apply both share and dataset permissions where your version requires it.
Test before importing: As one ordinary reader, open a sample and try to modify it. As a manager, make a permitted test edit. As an unrelated account, verify access is denied. Avoid cached administrator credentials contaminating the test.
Schedule local protection: Configure snapshots with retention matching how long mistakes might go unnoticed. Run scrubs at a suitable interval and check their completion.
Back up independently: Replicate snapshots to another properly administered TrueNAS machine over a private secure connection, or create an encrypted versioned offsite backup using a supported tool. Keep deletion rights and long-term retention appropriately isolated from the production server.
Save configuration & keys: Export TrueNAS configuration as supported by the installed release and securely retain the encryption keys, account records, ACL structure, mappings and network settings. Keep copies outside this same chassis.
Restore a realistic case: Restore to a separate dataset and verify an ordinary user's ability to open the material and restrictions against changes. For faster disaster recovery, test access to a pre-positioned read-only second-site copy over a VPN.
Business Considerations
A mirror is not a site disaster-recovery plan. If staff must access a case archive within four hours and restoring 700 GB over the internet exceeds that window, retain a usable second-site copy that can be mounted without first restoring the entire archive. A backup repository and a usable standby service are different things.
A business should also compare a DIY server against a supported appliance with published service terms, spare-part availability, and response coverage. Document whether a failure will be handled in hours, days, or simply when a replacement part arrives.
Acceptance checklist: Verified case inventory, correct permissions, working SMB path, local snapshot restore, offsite or second-site restore, measured time to first usable record, and an administrator other than the primary operator who can locate the recovery instructions.
15. Build C — Website + Nextcloud on Linux, Proxmox or TrueNAS
Example goal: A club or small office wants a public website plus private files with browser and mobile access. The public site should not have direct access to internal business shares. It should remain available if practical even when the storage host must be serviced.
Option 1: Bare-Metal Linux
Install a currently supported Linux Server release, configure updates, create separate service accounts and datasets/volumes, deploy Caddy for the website, and install Nextcloud using a method supported by its upstream project. Use official deployment instructions and stable container versions rather than copying arbitrary community Compose fragments.
This is often sufficient for a modest site and a handful of users, but all applications share the host's patch and failure schedule. Separate backups must cover the database, configs and user data.
Option 2: Proxmox VE With Separate Guests
Install Proxmox VE on compatible hardware. Set a fixed management address, secure administrative access, and keep the UI on a management LAN/VPN.
Reserve RAM and disk for the Proxmox host. Create one supported Linux VM for the public website or edge reverse proxy and another for Nextcloud. Separate guests reduce application blast radius, but do not create physical redundancy on one machine.
Decide where virtual disks and Nextcloud data live. Make mounts and external filesystems explicit, and document whether VM backup jobs actually include those bytes. A virtual disk on an external NAS creates a dependency on that NAS.
Install the public site (Caddy static files or a supported CMS stack) and deploy Nextcloud AIO following its supported steps. When deploying AIO behind an external reverse proxy, use the official reverse-proxy variant and configure the approved backend port, address, trusted-proxy settings, and certificates.
Create users and groups, set quotas and shared folders, enable MFA for administrators, and validate file access from a desktop and phone. For browser document editing, select and test a compatible Collabora or ONLYOFFICE deployment and review its licensing/resource use.
Protect the guests with scheduled backups, ideally on a physically separate Proxmox Backup Server, plus an independent offsite copy. Use the application's backup workflow for consistent Nextcloud restoration. Test guest recovery into an isolated environment with a different guest ID/network, preventing duplicate IPs and accidental production activity.
If the public site must survive an office outage, host its primary or static failover on an independently connected VPS. Real HA is a designed combination of compute, storage, quorum, networking, fencing and promotion—not merely two machines with identical files.
Option 3: Nextcloud as a TrueNAS App, Behind NPMplus
Already have TrueNAS? You may not need a second Linux host. Our Deploy Nextcloud on TrueNAS SCALE; Behind NPMplus SSL Proxy walks through the native app-catalog/dataset and HTTPS proxy approach. Follow the instructions appropriate to your specific TrueNAS and app versions. Record the application datasets, database files, proxy configuration, certificates, and the exact app-specific backup and restore workflow.
The AIO-specific Borg backup mechanism is not automatically the backup method of an app-catalog Nextcloud deployment. Protect all required application components in a consistent recovery point. Avoid following commands from a different deployment model without checking their paths, permissions and supported interfaces.
Optional Performance Detail: Nextcloud notify_push
Some self-managed Nextcloud installations use the notify_push Client Push app to reduce polling and notify connected clients when changes occur. It depends on a properly configured Redis and an independently running push process in some deployment methods. The feature's specific installation and proxying requirements vary: do not add a second push server if AIO already manages one.
For a conventional installation with a separately running push process listening on 127.0.0.1:7867, the upstream documentation offers this Caddy pattern inside the appropriate site block:
handle_path /push/* {
reverse_proxy http://127.0.0.1:7867
}
Then, through the supported occ entry point for that installation, set the external URL and run its tests:
# Conceptual commands; use your install's supported occ invocation:
occ app:enable notify_push
occ notify_push:setup https://cloud.example.org/push
occ notify_push:self-test
Caddy handles WebSocket proxy upgrades without the manual Nginx Upgrade boilerplate used in some older examples. However, verify the port and routing from inside the actual network: in Docker, 127.0.0.1 usually means the current container, not every other container.
Proxy Trust: A Small Detail With Big Security Consequences
Nextcloud should trust only the actual reverse proxy address(es) that legitimately forward client IP headers. An overly broad entry such as 172.16.0.0/12 may include containers that are not trusted proxies and can enable spoofed client addresses. This is why the generic network range in the advanced research draft should not be copied as a universal recommendation.
In a conventional installation, a narrowly scoped example in config.php might look like:
// Illustration inside an existing Nextcloud $CONFIG array:
'trusted_proxies' => ['10.20.30.10'],
'overwriteprotocol' => 'https',
Replace 10.20.30.10 with the specific Caddy/NPMplus proxy address or a tightly controlled proxy subnet. Prefer the configuration mechanism documented for your deployment, rather than hand-editing files managed by AIO or the NAS app system. Incorrect trusted headers can undermine rate limits and audit logs. See Nextcloud's reverse-proxy security guide.
Website Software Choice
A static website is the simplest to keep patched and restore: store versioned HTML/CSS/images and a deployable release. WordPress provides browser editing but requires database backups, regular updates, tested plugins, and stronger administrative controls. Any site that accepts payments, appointments or contact forms needs a verified transaction and notification flow. A page that looks correct in a browser does not prove its forms actually deliver submissions.
16. Build D — Domain Email Without Depending on Your House
Example goal: A small business wants control over domain mailboxes while avoiding residential power, ISP and public-IP constraints.
Why Mail Is Usually the Hardest Service
Email depends on a network of other organizations accepting and delivering messages, not merely on a working web interface. The mail server needs properly configured DNS, authentication, spam filtering, malware policy, reasonable IP reputation, reliable outbound transport, storage integrity, and an administrator prepared to investigate delivery failures. If the business depends on invoices, appointments and support requests reaching customers, do not move mail first as a casual experiment.
Choose an Operating Model
Step-by-Step Mail Server Preparation
Qualify infrastructure before buying: A supported Linux VPS should allow the required SMTP connectivity, stable IPv4/IPv6 as used, PTR reverse DNS management, adequate disk performance and mailcow's minimum resources. Current mailcow prerequisites specify 6 GiB RAM plus 1 GiB swap as the minimum default configuration and recommend larger allocations as users/concurrency grow. LXC and some virtualization environments are not supported for mailcow; use the officially supported architecture.
Keep domain control external: Secure the registrar and DNS provider with MFA. Maintain a recovery contact email address outside the domain being moved. You must be able to correct MX records when the new mail service is down.
Install via upstream documentation: Follow mailcow's official installation rather than an old paste of Compose files. For a compatible Synology, use the supported MailPlus Server package and model documentation instead.
Create identities: Set the server's FQDN (for example mail.example.org), certificate, production domain, mailboxes, aliases and reporting address. Keep SMTP submission authenticated. Never operate an open relay.
Publish DNS: Configure A/AAAA, MX, SPF, DKIM, DMARC, and PTR with the actual host and sending services. Verify DNS propagation externally, not just in the DNS control panel. Exact record examples are in Part 2.
Test sending and receiving: Send from the pilot mailbox to multiple unrelated mail providers, inspect received headers for SPF/DKIM/DMARC and unexpected spam placement, reply from those accounts, and confirm delivery on mobile data.
Test recovery: Restore a mailbox and message attachment in an isolated environment. Check account access, aliases, signing material, spam filtering, and the ability to send through the selected relay or server.
Assign daily ownership: Review queues, TLS renewal, abuse/blacklist reports, missed backups, free storage, and suspicious account sign-ins. Maintain a procedure for responding when a provider defers mail or a sender is compromised.
Inbound Backup MX Is Not Instant Mailbox Failover
A properly configured independent secondary MX can accept and queue inbound messages when the primary is down, then attempt later delivery. It must have the accepted-recipient list, anti-spam policy, TLS and anti-relay controls. It does not make users' existing mailbox history or webmail available. If mailbox continuity is required, plan a separate standby with tested data synchronization, identity, fencing and promotion.
Business recommendation: For most first-time self-hosters, build the file cloud and website first. Keep mail on the present provider until the team can demonstrate the new mail system's deliverability, monitoring, backup and rollback process.
17. Monitoring, Maintenance & Failure Planning
A system is not resilient merely because it has redundant disks. A resilient installation detects failures, tells someone, and can be restored within a measured time.
Independent Monitoring
Deploy Uptime Kuma or another external monitor at a second location. Monitor the public site, DNS, TLS expiration, important TCP services, backup freshness, drive alerts, and resource capacity. A mail server needs more than a port-open test: periodically send a uniquely tagged message through a controlled test mailbox and verify real receipt. Alerts should reach a phone or external address that survives the primary system's failure.
Operational Schedule
The minimum go-live test is simple: an ordinary user can do a real task, the system alerts someone if it fails, and an administrator can restore that task from a backup that is not stored solely on the same machine.
Next is Part 2: Migrate, Verify & Recover
This guide is educational. Product availability, license terms, software interfaces, ISP restrictions, utility tariffs and pricing can change. The procedures include illustrative domains, addresses and example commands; adapt them to the actual supported software release and test in a non-production environment before applying them to important data. Cost examples are estimates, not quotations. Last technical review: November 12, 2026.
No comments:
Post a Comment