Hello everyone,
Since introducing SAGE Edu 1.0 and 1.1, I have been running SAGE Edu in my homelab to understand its infrastructure requirements and explore how to keep deployment and maintenance costs as low as possible., this post is not about the project itself. It is about the infrastructure that runs it, and why I built it the way I did.
1. Why a homelab? Two constraints in Angola
I am an independent developer based in Angola, where I see two important challenges when building and deploying software.
- Foreign-currency costs. Cloud servers and hosting are billed in USD or EUR by foreign companies. For an independent developer, and even more for a school, paying recurring bills in a foreign currency is expensive and unpredictable, because exchange rates and international payment restrictions make it hard to plan.
- Aging technology. Most hardware available here is 4 to 7 years old. New equipment is expensive to import, so the realistic target for many institutions is software that runs well on modest, older machines.
These constraints influence how I approach software development and infrastructure. Instead of assuming access to powerful servers, expensive cloud services or the latest hardware, I want to understand how far we can go with modest resources and open-source technologies.
This is one of the reasons I chose Tryton as the foundation for SAGE Edu.
With the SAGE Edu 2.0 release planned for November 12, 2026, I would like to share my current homelab architecture, some of the decisions behind it, and the lessons I am learning along the way.
2. Physical infrastructure
My current homelab is built around relatively modest equipment:
| Component | Specifications | Purpose |
|---|---|---|
| Lenovo ThinkPad | Dual-core CPU E7500 @ 2.93GHz, 4 GB RAM, 500 GB HDD | Proxmox VE 9.x host |
| Virtual machine | 1 vCPU, 2 GB RAM, 64 GB disk | Application environment |
| Router | D-Link AC1200 | Local network and DHCP |
| Switch | 8 ports | Wired LAN |
| Internet | ISP, 10 Mbps advertised | Remote access and updates |
The physical host is not powerful by modern server standards, but it is sufficient for my current development and testing environment.
I deliberately started with hardware already available to me instead of purchasing a dedicated server or immediately renting cloud infrastructure.
This approach helps me experiment with deployment, resource management and system administration while keeping initial costs under control.
It also raises an important question for the project: How can we build maintainable institutional software that remains practical to deploy when hardware and budgets are limited?
3. Software stack
- Virtualization: Proxmox VE 9.x
- OS: Ubuntu Server 24.04
- ERP framework: Tryton 7.0
- Database: PostgreSQL 16
- Remote access: Cloudflare Tunnel
- Website and documentation: GitHub
The current setup is intentionally simple. I want to understand the actual resource requirements of the application before introducing additional infrastructure components.
4. Architecture
Internet
|
Cloudflare
(DNS + Tunnel, no open ports)
|
+-----------------+------------------+
| | |
Website Application Documentation
(GitHub) (Cloudflare Tunnel) (GitHub)
|
Proxmox
|
Ubuntu Server VM
|
+--------+--------+
| |
Tryton PostgreSQL
port 8000 port 5432
The Proxmox host manages the virtual machine, and the application services run inside Ubuntu Server. Cloudflare Tunnel provides a way to reach the application remotely without exposing the application server directly through inbound router ports.
This separation gives me an independent application environment and allows me to manage the virtual machine without modifying the underlying virtualization host. This is particularly useful in my environment, where I want to make the demo accessible without having to manage direct inbound connectivity to my home network.
The public-facing resources are separated from the application infrastructure:
- Project website: https://sage-edu.comunidadedosaber.ao
- Demo application: http://app.sage-edu.comunidadedosaber.ao
- Documentation: https://docs.sage-edu.comunidadedosaber.ao
Note: the demo currently runs over HTTP because Cloudflare’s free certificate does not cover second-level subdomains such as app.sage-edu.comunidadedosaber.ao. I plan to pay for a certificate so that TLS works.
5. What this setup teaches me
For me, the homelab is more than a way to reduce costs. It is a practical environment for understanding the operational requirements of an application with limited resources, and devilry an software for Institution that need to have ownership of the technology and the data.
Running SAGE Edu on limited hardware forces me to pay attention to several areas:
- Resource management: Understanding CPU and memory consumption.
- Database management: Configuring PostgreSQL and protecting persistent data.
- Network security: Controlling external access to the application.
- Availability: Understanding the limitations of a home internet connection and hardware.
- Backups and recovery: Developing reliable backup procedures and testing restoration.
- Deployment: Making the environment easier to reproduce, maintain and upgrade.
These are important considerations even when the application itself works correctly. For example, having a working application is not enough if a disk failure could result in data loss or if a server restart requires manual intervention. There are still several areas I need to improve, particularly monitoring, automated recovery, backup restoration testing and disaster recovery.
I also recognize that my current setup is a development and demonstration environment, not yet a production-ready deployment for an institution that depends on the system for its daily operations. Nevertheless, it provides a useful foundation for understanding what is required to move from a working application to a reliable service.
6. Next: SAGE Edu 2.0
My next milestone is November 12, 2026, when I plan to release SAGE Edu 2.0 on Tryton 8.0.
As I prepare for this release, I also want to improve the deployment documentation and make the process easier for other developers to reproduce.
I am particularly interested in keeping the architecture understandable and maintainable rather than introducing complexity before it is necessary. For institutions working with limited budgets, the cost of operating software matters just as much as the initial cost of acquiring it.
My goal is to continue exploring how Tryton and other open-source technologies can support this approach.
7. Feedback from the Tryton Community
I would appreciate feedback from developers and system administrators who have experience running Tryton in resource-constrained environments, or from anyone who has tried installing or using SAGE Edu.