This article explains why the ActivityInfo Self-Managed Server does not support a two-tier deployment.
We designed our self-managed server to be a powerful, reliable, and secure platform that is simple to install and maintain. To achieve this, we use a single-instance architecture. This design best serves organizations, especially those with limited IT resources.
Many IT standards recommend a two-tier architecture, with the application on one server and the database (like MySQL or PostgreSQL) on another. While this model works for many applications, we chose a different design for ActivityInfo. This article explains our design and how to secure your single-server deployment.
Why the self-managed server avoids a two-tier architecture
A two-tier architecture can improve security by placing the database on a seperate (virtual) machine behind a firewall. However, this model would make ActivityInfo slower and harder to maintain. We decided against a separate database server for two reasons:
Data-intensive features are slow with separate servers
Many ActivityInfo features, like the duplicate record scanner, are data-intensive. They work by making complex comparisons of many records.
In a two-tier model, the application would need to pull the entire dataset over the network from the database server to perform this analysis. This large data transfer creates network latency, which slows down the application and uses a lot of bandwidth. The performance of these features would be much worse, especially for customers with large databases.
A single server is simpler to maintain
A key goal for our self-managed server is simplicity for teams that cannot dedicate a full-time employee to manage it. A two-server setup requires you to configure, monitor, and maintain two servers, their operating systems, the network rules between them, and separate database user accounts. This complexity goes against our goal of a low-maintenance solution, and increases the risk of misconfiguration.
Single-server design
The ActivityInfo self-managed application is a single, self-contained Java application. This single process includes both the web server and an embedded SQLite database engine.
An embedded database is a library that is part of the ActivityInfo application. Your entire database is stored in a single file on the same server.
This single-server model offers several advantages:
- High performance: The application communicates directly with its database file on the local disk, so data access is fast. This avoids network delays and allows complex, data-heavy features like the duplicate scanner to run efficiently, even on large datasets.
- Simplicity: You only need to install, configure, monitor, and back up one component. This reduces complexity and the chance of configuration errors.
- Reliability: With fewer parts and no network connection between the application and its data, there are fewer points of failure.
Comparison with our hosted service
Our hosted service at ActivityInfo.org does use a multi-tier architecture. This service is supported by a full team of engineers and 24/7 monitoring and so can afford to be more complex. We use extensive, multi-level caching to overcome the impact a multi-level architecture on data-intensive features. Watch our Introducing the Self-managed ActivityInfo version webinar for a comparison between the two products.
Securing your ActivityInfo self-managed server
A single-server architecture can be just as a secure as two-tier deployment if properly configured. If you do not have a full-time team managing your ActivityInfo service, a single-server deployment is likely to be more secure as it lowers the risk of configuration error.
Here are steps you can take to secure your self-managed server:
- Allow access only to ports 80 (http) and 443 (https). These are the only ports that the ActivityInfo server listens for, and http (insecure) requests will be automatically redirected to https. SQLite is an embedded database system and does support network connections.
- Disable SSH or RDP access to the server, or restrict SSH access to a “bastion” host within your own network.
- Choose a minimal operating system for the ActivityInfo server, such as Alpine Linux, Ubuntu Minimal, or Google Cloud’s Container-optimized OS , in order to minimize the attack surface of the (virtual) machine.
- Enable unattended operating system updates.
- Consider deploying a Web Application Firewall (WAF) in front of the ActivityInfo Server. Cloudflare’s WAF is known to work well with ActivityInfo.
The points above are important steps to take when deploying specifically the self-managed version of ActivityInfo. However, the most important risks for any ActivityInfo database come from authenticated users:
- Configure Single-Sign On (SSO) to reduce the risk of password-fatigue, and to ensure that staff members loose access to the database when they leave your organization.
- Configure roles for your databases that follow the principle of least-priviledge.