Shared cloud, dedicated project, or your own servers
Alano is a cloud-native product, and the shared cloud is what almost everyone should use. For organisations that cannot put customer data on a shared platform, the same system can be delivered dedicated or built to run entirely inside your own network.
The three options
| Shared cloud | Dedicated project | On-premise | |
|---|---|---|---|
| Who operates it | Alano | Alano | Your IT team |
| Database | Managed PostgreSQL, shared platform | Managed PostgreSQL, isolated project | PostgreSQL on your servers |
| Isolation | Row-Level Security on organization id | Row-Level Security plus a separate project | Row-Level Security plus your network |
| Sign-in | Email code, password, Google | Email code, password, Google | Entra ID or Active Directory, via OIDC or SAML |
| Cloud email provider | Cloud email provider | Your corporate SMTP relay | |
| AI features | Included | Included | Excluded — they require outbound calls |
| Internet access required | Yes | Yes | No |
| Availability | Today | Today | Scoped engagement |
Most customers are on the shared cloud and need no decision here.
What on-premise actually means
On-premise Alano is delivered as a project, not a download. We re-package the product to run as a single deployable artifact inside your environment, and your team operates it. We are explicit about this because "self-hosted" is often sold as a checkbox when it is a piece of work.
What carries over unchanged:
- The database schema: The same PostgreSQL model, running on your servers instead of a managed platform.
- The access rules: Row-Level Security policies, group hierarchy, record visibility and field-level permissions transfer intact — they are database objects, not cloud features.
- The audit engine: The same triggers, writing the same before-and-after values to the same append-only log.
- The application itself: The full interface and the approval and workflow framework, served from the single artifact with no separate deployment.
What changes:
- Authentication: Managed sign-in is replaced by your Microsoft Entra ID or Active Directory over OIDC or SAML. No passwords are stored by the application.
- Email: Cloud email providers are replaced by your own corporate SMTP relay.
- AI-assisted features: Removed from an isolated build. Every AI feature calls out to a model provider, so a deployment with no internet access cannot include them. All non-AI functionality operates unchanged.
- Scheduled work: Managed cron is replaced by a scheduler inside the application service, coordinated through the database so jobs run exactly once across instances.
Running it yourself
- One versioned artifact plus a database initialisation script. Deployment is copy the artifact, set the configuration file, start the service.
- The service is stateless, so it runs behind your load balancer across as many instances as you need, with no sticky sessions.
- Upgrades are rolling — old and new versions serve concurrently while instances are replaced.
- The application runs as an unprivileged service account and connects to PostgreSQL with an ordinary least-privilege user. No administrator or DBA rights are required anywhere.
- Backup and restore is standard PostgreSQL, using whatever tooling your organisation already runs.
Working out which one you need
Dedicated and on-premise deployments are scoped per organisation — the answer depends on your identity provider, your network constraints, your data-residency obligations and which integrations you need. We would rather talk it through than publish a number that turns out not to apply to you.
Overview | Architecture | Compliance & privacy | Privacy Policy | Chrome Extension Security | Contact