A stronger home for independent reporting
Keep publishing decisions in your hands while treating source protection as a separate discipline.
Content revised · English
- Architecture to evaluate
- Public publishing / protected intake
- Prepared starting points
- 5 plans
- Responsibilities
- Application, rights and recovery
A fit shortlist, not installed software or live inventory.
Keep these in view.
- Public publishing / protected intake.
- Protect the source beyond the server.
- Keep the publication recoverable.
Public publishing / protected intake
Publication, source intake and editorial workstations are separate systems. A public WordPress or Ghost site can be hosted and cached independently from a sensitive document workflow. SecureDrop and onion services have their own deployment model; evaluate their maintained project guidance rather than treating a generic VPS as a complete source-protection system.
Protect the source beyond the server
Use a threat model for the reporter’s device, credentials, document metadata and communication. Client-side encryption and narrowly shared access can reduce exposure, while backups protect continuity. An alias and a privacy-focused payment at a provider that offers one do not remove browser, device or application records. OmbraHost does not accept Monero.
Keep the publication recoverable
Prepare an independent publishing copy and restore procedure before a difficult story is released. The public site may need a WAF and rate limits in addition to network mitigation. Preserve a documented process for substantiated legal requests instead of relying on a blanket “ignored” claim.
Publishing and source protection
A reporting website and a confidential submission system have different risks. Separate public publishing, editorial access and sensitive source material. A server region can be part of the decision, but it cannot protect a compromised journalist's device.
A durable publication
Use a reproducible deployment, restricted administration and independently encrypted backups. Keep domain access, server access and editorial accounts distinct so a single credential failure has a smaller impact.
Plan for the difficult day
Test restoration and export before an incident. Document who can publish updates, respond to complaints and rotate credentials. Obtain specialist support when handling high-risk source submissions.
Capacity to consider.
Match these starting points to the representative application. Software installation and live inventory are not connected; the exact specification and period total come from the catalogue.
Veil Studio
Manage up to five websites and 25 mailboxes within 25 GB of NVMe storage and a 250 GB monthly transfer allowance. Daily backups with seven-day retention, SSL certificates and a CDN make this a broader foundation for several sites under one account.
- Storage
- 25 GB NVMe SSD
- Transfer
- 250 GB / month
billed monthly
Umbra 2
Give web applications, containers or a private tunnel two AMD EPYC virtual CPUs, 4 GB of ECC memory and 60 GB of NVMe storage. Root access on KVM, a 1 Gbps port and 3 TB of monthly transfer provide more room than the entry configuration without moving to dedicated hardware.
- Compute
- 2 vCPU (AMD EPYC)
- Memory
- 4 GB DDR4 ECC
- Storage
- 60 GB NVMe SSD
- Transfer
- 3 TB / month
billed monthly
Umbra 4
Balance four AMD EPYC virtual CPUs and 8 GB of ECC memory with 120 GB of NVMe storage for several services or a growing application. This KVM configuration includes a weekly snapshot, 6 TB of monthly transfer on a 1 Gbps port and a 20 Gbps network mitigation tier.
- Compute
- 4 vCPU (AMD EPYC)
- Memory
- 8 GB DDR4 ECC
- Storage
- 120 GB NVMe SSD
- Transfer
- 6 TB / month
billed monthly
Cipher Team
Give a small team five mailboxes sharing a total allocation of 50 GB, with a custom domain and a shared address book and calendar. Roundcube and native mail clients provide access, while Rspamd filtering helps manage unwanted mail without replacing your own message-handling policies.
- Storage
- 50 GB total
billed monthly
Eclipse Six
Reserve a physical Xeon E-2236 server with six cores, 12 threads and 32 GB of ECC memory for your own operating system and applications. Two 480 GB NVMe drives form a mirrored RAID-1 configuration, accompanied by IPMI access, a 1 Gbps port and 30 TB of monthly transfer.
- Compute
- Intel Xeon E-2236 (6c / 12t @ 3.4 GHz)
- Memory
- 32 GB DDR4 ECC
- Storage
- 2× 480 GB NVMe (RAID-1)
- Transfer
- 30 TB / month
billed monthly
Before this workload goes live.
- Check the exact plan’s CPU, memory, disk, transfer and port.
- Choose a listed region and verify the workload’s permitted use.
- Test the representative application and an independent restore.
Questions, answered.
Can a source reach an intake service over Tor?
An onion-service intake is an architecture to evaluate using maintained Tor and specialist project guidance. A public VPS and a secure intake system are different deployments; none is installed.
Does this eliminate session or contributor records?
No. The website uses a session cookie and stores private workspace records. A production intake application needs its own logging, retention and source-protection design.
What if a lawful request seeks contributor information?
The operator and publication need a verified request process and an accurate account of what records exist. No blanket refusal or untraceability promise is made.
Is SecureDrop included?
No. Its project-specific architecture, deployment requirements and maintenance must be evaluated separately; a catalogue plan is not a turnkey SecureDrop installation.
What is kept in my account workspace?
Your configuration, selected plan, image, location and billing term are kept with the order and payment request references. Quotes, payment-state reads and support conversations remain linked to your account. Read fulfilment details separately from payment status.