User Guide

This section documents the Ferris Management User Interface (UI) in detail, so that you can quickly understand how Ferris is used effectively. Practical examples will further help in obtaining hands-on experience.

The Ferris Management UI

The Ferris Management UI is a light weight front-end, through which all Ferris Components are managed and monitored. The Management UI is intentionally kept simple, with a structure that makes navigation fast and effective.

Extending the user interface is easily possible with the built-in Ferris Application Builder (FAB). This can become very useful for use cases demanding user input.


The primary purpose of Ferris Management UI is for development teams to setup projects and services and orchestrate them to fully fledged applications.

Through the user interface, teams are enabled to perform the following tasks:

  • Manage Projects
  • Manage and orchestrate Services
  • Schedule, trigger and run Jobs
  • Integrate with Git Repositories
  • Manage Security
  • Log and Monitor executions and jobs

Users and Roles

The Ferris Management UI serves a number of different audiences and roles, namely:

  • Development and ebgineering teams, developing applications, uses cases and software projects
  • DevOps and GitOps teams, responsible for maintaining, extending, deploying and operating applications
  • Security Leads mainintaining users and privileges
  • Admins, such as Project Leads maintaining projects

Ferris Components

The Ferris Platform follows the principles of Event based Services and Integrations Architecture. As a result, Ferris observes a strict, yet easy to understand paradigm of Microservices based engineering.

In the following section, the Ferris Components used to establish Microservices and Event based Services and Integrations Architecture are explained in more detail:


Projects is a purely logical concept within Ferris, serving the purpose of separating services and entire applications, including their development teams from one another.

Within a project, teams can connect to their Git Repos and integrate code snippets, microservices and APIs. The real-time integration of these integrations greatly reduce any deployment overhead and thus make an immediate code evaluation possible.

Secrets may also be setup on a project basis, effectively enabling project level integrations and security.


Services are one of the core elements of the Ferris Platform. A Service represents one or many code sippets, microservices or APIs. It can be augmented by configuration and manifest files, and together each Service represents a fully fledged process or micro application.

Ferris Services are extremely capable and powerful objects, since they are reusable anywhere and can be triggered by any type of Event, be that:

  • Trigger Event, by any internal or external cloud-based event
  • Cron Schedule, on a preset schedule
  • Manually, from within a Service


Events are the triggers kicking of a Service. As with Services, Events are kept flexible, and can take any form, such as a manual file upload on some company internal system, a periodic file ingestion process on a data platform, or a high-throughput monitoring of trading executions.

Events may happen anywhere in the realm of global cloud services or internally on legacy inhouse systems. Very often, events happen on a wide variety of such systems and services.

The nature of Events is that each Event a) listens to something particular happening, and then b) triggering one or more services.

Events and Services enter a symbiotic relationship: Events trigger Services, and in turn a completed Service may trigger one or more Events. Thus the relationships between Services and Events can be:

  • One to one (1 : 1)
  • One to many (1 : n)
  • Many to many (n : n)


Jobs are the actual running of Services and Events. As mentioned earlier, Jobs may be triggered either manually, on schedule, or by a trigger event.

Ferris Jobs are powerful because they are universally executable by Developers and DevOps alike:

  • Developers: setup and execute Jobs to test Services
  • DevOps: integrate Services with (Kafka) event triggers or schedule recuring Jobs through Cron


Similar to Projects, Taxonomies or Tags are a logical concept to help facilitate the management of the diverse Ferris elements.

One difference to Projects is though, that Tags may be used across Projects.


As one of the first enablers of GitOps, Ferris provides a secure integration with Git Repos, enabling a direct embedding of code in Ferris Services.

As a result, real-time testing as well as no-code deployment of new Services and APIs is made possible with one simple integration.

Note: Ferris supports integrations with GitHub, GitLab and Bitbucket

File Uploads and Object Storage

In order to faciliate development and testing, but also embeddable in end user applications, Ferris provides an S3 based file upload mechanism.


The Ferris Platform makes extensive use of Secrets. Secrets may be applied on three levels:

  • Services, to be used on a partcular Service only
  • Projects, to be used within a project realm, and by the project members only
  • Platform, may be used by all projects, services and users of the platform

Secrets are stored within the Ferris Secrets Vault


Ferris Users and Roles are managed in the Security section. Users and Roles are managed by one or more designated Security Leads.

Roles and Permissions are freely configurable to specific organization, project or application needs.

Ferris integrates with any external Information Access Management (IAM) system, and SSO, Auth0 or SAML method.

Landing Page (Dashboard)

Overview of the Ferris FX Dashboard.

Login and Registration

Logging into Ferris, registering a new or performing self-service actions.


Projects are used to define logical teams and separate definitions and access of like services. Projects control member access to services and executions as well as to Git Repos and Secrets.


How to add Tags and the importance of Taxonomy.


How to use CronJob to schedule regularly recurring actions.


How to configure a package to be triggered bt the FX Router when a specific type of event is observed on the platform.

Executions - Packages

How to use the Executions/Packages Framework for script automation and package (execution) triggering.

Logging and Monitoring

Development Lifecycle of an FX Service.

Last modified November 24, 2023: update (f4bc5ea)