Architecture and hardware requirements

This document acts as a reference point for the logical design of Canopy, and also provides guidelines on specific deployment scenarios.


Canopy is comprised of three main components:

  • Application/web service (web tier, including application server and local file storage system)

  • Database layer

  • Document generation service (DOCX and PDF)

It is possible to run all three components on the same hardware - assuming the minimum requirements are met and planning of storage is undertaken. However, it is equally possible to deploy Canopy in different configurations - e.g. placing the web tier and database service on different services and storage on a NAS/SAN.

Alternative deployment guides will be made available shortly. For any specific questions, please contact

Logical design


Services and Ports

Canopy communicates over the following TCP ports:

Service Group


Port (Protocol)

Publicly Accessible?



Canopy application server

Web Server

443 (https)


Yes - hardened TLS configuration out of the box

This is a standard web service, running on nginx by default (Apache also supported). It is also the primary, and only, interface that needs to be accessible to users of the application. The Web Service acts as a reverse proxy to the Application Service, for both user access and API (RESTful) access.

A self-signed certificate is used by default, which should be replaced with a production ready certificate.

Canopy application server

Application Service

8000 (http)


Localhost configuration by default.

The Application Service is built on top of Django and is typically bound to localhost only. If network communication is required (e.g. for large scale deployments), this service is wrapped (reverse proxy) via another Web Server layer, which would use the default TLS hardened configuration.

Canopy application server

RabbitMQ server

5672 (amqp)


Localhost configuration by default; default username/password.

RabbitMQ is a backend message queue for running asynchronous jobs via Celery.

RabbitMQ can be configured to run over TLS, which may be a requirement under larger/enterprise deployments. Specific guidelines are available on the RabbiMQ site:

It is recommended that the default username/password be changed on install, even though the service is restricted to localhost.

Canopy database server

PostgreSQL (default)

5432 (pgql)


Localhost configuration by default; default username/password accessible through a user-restricted admin script.

PostgreSQL is the primary database supported by Canopy.

Canopy report server


8181 (http)


Localhost configuration by default; no authentication required.

This service accepts a DOCX document template and an XML data source and returns a generated DOCX file to the Application Service.

This service can be run on an alternative server (for load distribution). In such a scenario, we recommend using nginx as a front-end proxy, which can be secured via TLS.

Canopy report server

PDF converter

9016 (http)


Localhost configuration by default; no authentication required.

This service accepts a DOCX and returns a DOCX and PDF to the calling application.

This service can be run on an alternative server (for load distribution). In such a scenario, we recommend using nginx as a front-end proxy, which can be secured via TLS.


Mail routing

25 (smtp)


Outbound only service, for mail routing.

This is a dependency for sending email-based notifications to users. Outbound firewall requirement.

Deployment scenarios

Single server

By default Canopy will set up a single server instance using the standard service protocols listed above.

Larger and enterprise deployments

Within enterprise environments, service layers may be available for databases. Canopy supports separation of the following modules on separate servers:

Web server

the web server can be run on its own instance. The web server configuration would need to be configured to connect to the application server on the exposed port (default: 8000). Multiple servers can be deployed in high availability environments.

Application server

the application server can be configured on a separate server.

Database server

Canopy requires a single database server. This database can be hosted on a network connected server. The database URL and port must be configured in the canopy.ini file on the application server. Database replication is not currently supported.

Report server

both the Docserver and the PDF converter can be deployed to a separate server (or servers) in order to offload the resource intensive operation of document generation. Both of these services can be deployed using TLS to encrypt network communications.

For configuration guidelines, see: TBC.

File locations and storage

Canopy stores data in the following locations:



Requires backup

Disk space required


Canopy system configuration and license files.




Canopy binary data that is managed by the Linux distribution’s package manager.




User data that is imported into Canopy and generated by Canopy e.g. imported tool data, uploaded screenshots, report template files, generated reports, custom plugins.


Depends on amount of data stored and generated inside of Canopy. This ranges from a 1-5GB per year for small installations (< 10 users) and 50GB+ per year for larger installations.


Many services that Canopy depends on will store their data here, e.g. local DB (if in use) and rabbitmq. Other system related daemons will also store their data here, e.g. systemd logging

Not directly. DB should be backed up separately and using DB specific procedures.

Database (RDBMS specific)

Yes, using RDBMS specific backup procedures as recommended by the RDBMS vendor.

As files are NOT stored in the DB, it ends up being somewhat small in comparison to the main data directory. Depends on RDBMS. Postgresql would require maybe 1GB per year for small/medium installations.

Calculating storage space

Storage requirements for Canopy vary greatly based on the planned use of the system. If Canopy is going to be used to store data, including state files from proxy tools, code repository dumps, etc., then more disk space will be required. If such information is stored on an external environment, references can be used inside of Canopy instead via the description fields.

A typical usage scenario calculation might consist of:

  • Average data per project: 1GB

  • Estimated number of projects per year: 250 (distributed across the team)

  • Estimate space requirement (per year): 250 * 1GB = 250GB + 2-5GB for the database server

Total estimate for 1 year might be ~255GB, which should arguably rounded up to 300GB.

It may be appropriate to project for a 3-5 year period, towards an upper limit.