Guardhouse Cloud and self-hosted
The Guardhouse tenant dashboard is used in both deployment models. The difference is who operates the runtime, data services, network, certificates, backups, upgrades, and monitoring.
Guardhouse Cloud features, regions, managed defaults, custom domains, self-hosting rights, container access, and support commitments depend on your plan or agreement. Confirm those terms before designing an operational model.
Compare responsibilities
| Area | Guardhouse Cloud | Self-hosted |
|---|---|---|
| Guardhouse runtime | Operated by Guardhouse under the selected service plan | Deployed and operated by your organization |
| Version rollout | Managed as part of the Cloud service | Scheduled, tested, and rolled back by your operator |
| Default domain and TLS | Managed Cloud domain and certificate | Your DNS, reverse proxy or ingress, and certificate |
| Custom domain | Available when enabled for the workspace | Configured directly in your deployment |
| PostgreSQL and Redis | Operated as part of the Cloud environment | Provisioned, secured, monitored, and recovered by you |
| Runtime secrets | Cloud platform responsibility; tenant provider secrets remain yours | Your secret store, access policy, rotation, and audit |
| Email and storage | Managed defaults may be available; custom credentials remain yours | Your providers and credentials |
| Tenant configuration | Your administrators | Your administrators |
| Application integration | Your application and API teams | Your application and API teams |
Service-plan and contractual terms—not this page—define Cloud backup, retention, recovery, and availability commitments.
Your responsibilities in Guardhouse Cloud
Even when Guardhouse operates the infrastructure, your organization still owns:
- client types, redirects, origins, and token lifetimes;
- API audiences and scopes;
- authentication, signup, and MFA policy;
- users, roles, permissions, and System Access;
- branding, legal links, and profile choices;
- credentials for custom email and storage providers;
- webhook endpoints, secrets, and event processing;
- DNS changes requested during custom-domain setup;
- token validation and authorization inside your APIs.
Use the domain workflow shown for the workspace. If custom-domain controls are absent, use the customer portal or contact Guardhouse support.
Self-hosted reference topology
A production self-hosted deployment normally contains:
- a public load balancer, reverse proxy, or ingress that terminates TLS;
- the Guardhouse application on a private network;
- PostgreSQL for persistent tenant and identity data;
- Redis as a protected runtime dependency;
- an object-storage provider for uploaded tenant content;
- an email provider for invitations and authentication messages;
- centralized logs, metrics, alerts, and certificate monitoring.
Run Guardhouse with a least-privilege identity and expose it only through the intended public HTTPS endpoint.
Configure the runtime
Use the configuration sources supported by your Guardhouse distribution. Treat complete tenant configuration as sensitive.
Configure at least:
- tenant identity and region;
- a strong encryption key;
- canonical server, website, and portal domains;
- deployment type;
- trusted forwarded-proxy addresses or networks;
- PostgreSQL and Redis;
- initial administrator bootstrap, when required;
- logging and optional error-reporting or observability settings;
- email and storage providers;
- external-service credentials required by enabled features.
Use a production secret store or a read-only secret mount. Do not commit tenant configuration, provider keys, database passwords, or bootstrap credentials to source control or bake them into the image.
Configure network and TLS
- Publish one canonical HTTPS hostname.
- Terminate TLS at a trusted proxy or ingress.
- Forward protocol and client-address headers.
- Configure Guardhouse to trust only the actual proxies and networks.
- Keep data services and the application's private listener off the public internet.
- Test authorization callbacks, logout, passkeys, and generated links through the public hostname.
Incorrect forwarded-proxy trust can create redirect loops, generate HTTP callbacks, or record the proxy instead of the client address.
Protect persistent state
Persistent application state can include identity data and cryptographic key material. Protect it as a security-sensitive dependency and include it in tested backup and recovery procedures.
A recovery plan should cover:
- PostgreSQL backups and restore testing;
- object-storage content;
- tenant runtime configuration and secret references;
- DNS and TLS configuration;
- the deployed Guardhouse version;
- provider and webhook rotation procedures.
Restore related state to a mutually compatible point. Losing cryptographic key material can invalidate protected application data even when other records remain available.
Deploy and upgrade
Guardhouse releases can include configuration and database-schema changes.
- Read the release notes and confirm configuration compatibility.
- Back up the database and tenant configuration.
- Test the version and migration against a staging copy.
- Use a controlled rollout and coordinate instances that share persistent state.
- Monitor startup and upgrade logs.
- Smoke-test discovery, login, logout, token issuance, API validation, email, storage, and webhooks.
- Keep a rollback plan that accounts for database compatibility.
A successful application health response is not a substitute for dependency and end-to-end readiness monitoring. Monitor data services, external providers, and authentication flows separately.
Next steps
- Apply the Security checklist.
- Use Troubleshooting for common integration and hosting failures.
- Configure tenant features from the Configuration overview.