Self-Hosted Deployment of Eramba, Open Source GRC Platform

Posted on December 19, 2025  •  4 minutes  • 825 words

Disclaimer: I don’t have any affiliation with Eramba Ltd. and this document serves as documentation of self-hosted Community (open-source) edition for future references.

Introduction

Eramba is a Governance, Risk, and Compliance (GRC) tool developed by GRC professionals, for GRC professionals.

A decade ago a community of CISOs built a simple tool that would get the job done - build a Risk Framework, certify PCI-DSS or achieve a SOC2 Report, etc.

Eramba GRC Software has a community edition which can be deployed as a docker container and also an enterprise edition. These are demo websites for Community and Enterprise versions.

Reasons for Choosing Eramba

From my perspective, having an open source and self-hosted tool with enough capabilities for GRC operations is very useful. Meanwhile, I only deployed it on a VM and tested certain capabilities and do not have extensive experience with the platform. These types of open-source options eliminate the need to purchase expensive solutions for companies but those platforms should be configured and operated. Due to that reason, even though it is open source, there will be operational overhead for utilizing that platform.

As they mentioned in their website, there are four main reasons to choose it:

1. Community: They say that community is more important than the company.
2. Simple: There may not be a need for consultation to third parties to effectively operationalize the platform.
3. Affordable: It is free. That is a game-changer while some other suppliers give hundreds of thousands of dollars.
4. Does the Job: The professionals had already used it.

Deployment

That’s the official Docker Installation guideline.

Pre-Deployment Configurations

A VM in any CSP could be enough to use Docker. At least 4 GB of RAM is required. In that case, Ubuntu 24.04 LTS is used in a CSP. Deployment will consist of four different containers: MySQL, Redis, Eramba, Cron.

1. After installing the Docker in the VM, clone the installation files.

git clone https://github.com/eramba/docker

2. In the .env file, there are some credentials that need to be changed and Public Address.

In public access section, a public or private IP or a domain can be configured.

PUBLIC_ADDRESS=http://{VM_PUBLIC_IP}

3. If the connection will be HTTP a change in configs of compose.yml should be completed.

eramba:
  volumes:
    - ./apache/vhost.conf:/etc/apache2/sites-available/000-default.conf

4. The port to access PUBLIC_ADDRESS should be configured in compose.yml to e.g. 80

eramba:
  ports:
    - 80:80

5. Lastly, containers should be deployed.

docker compose up -d

Post-Deployment Configurations

If the related network rules are configured, it should show the first login page.

During the registration, an email will be needed. After that Eramba Community Validation Token will be shared via email and be needed in the login page.

Regular Login Page:

After logging in to the platform, a system health check is recommended:

SMTP configurations can be completed for Gmail:

Policy Sharing Page, Policy Portal

Operators may create a specific page to share some compliance documents with different access levels e.g. public, private etc.

The related configuration can be enabled here:

After accessing as guest to Policy Portal (if enabled) a user can see that page:

Policy Portal Access Page:

Policy Portal Policy List:

A Policy Detail Page:

A Sample concept of webpage to share GRC related documents:

That is a sample Dashboard Page from Demo Website of Eramba Community Edition:

Conclusion

I’d like to thank every contributor of the Eramba Project. I’m not a GRC professional but it seems an easy to deploy and all-in-one platform for GRC tasks, internal or external audit operations etc.

I see that a central platform for different business units or stakeholders would increase efficiency of operations to decrease unnecessary email communications. But starting from deployment to management of the platform, I see that there is a need for allocation of enough time for operational efforts. It is not a platform to install and forget about it. If GRC professionals prefer to use that kind of platform, probably they will need to integrate with their ID provider service or other platforms.

It will require user and permission management. Even though those operational needs may create overhead, it is a sufficient solution due to its open-source and free, community edition aspect. Especially when we compare the some enterprises’ solution prices, instead of purchasing them, companies may hire 3 or 5 different personnel just for that platform and related infrastructure’s costs. Return on Investment would be easy to calculate and I think that only Operational Expense would be the case without any license, Capital Expense and enough to approve related budgets for those service requirements.

Operational Overhead Analogy by NotebookLM

Choosing an open-source tool is like being gifted a free vegetable garden. While you don’t have to pay for the produce (the software), you must still invest your own time and tools (operational overhead) to water, weed, and harvest it to get any value. Management must decide if they would rather pay a grocery store (a vendor) for the convenience or hire gardeners (personnel) to maintain their own plot.

Infographic Provided by NotebookLM