How addy works in your IT landscape

The architecture stays intentionally simple: addy as platform, one POD inside your network, and your Endpoints. No black box, no unnecessary complexity.

automate IT tasks easily and efficiently Empower others to get things done Keep it simple and smart

Infrastructure diagram

The diagram below shows the standard flow from request to execution on your target systems.

Architecture building blocks

1) Request

A user or a system sends a request via web or REST API. Parameters define the concrete job execution.

2) addy

addy manages Catalog, Jobs, and Requests in a multi-tenant way. Approvals and rules keep execution controlled.

3) POD

The POD runs as a Windows runner in your network and executes your PowerShell automations.

4) Endpoints

Endpoints are target systems such as AD, vCenter, Citrix, DNS/DHCP, or CA. Access can run via SSH, REST, PowerShell, or WinRM.

Request flow in 4 steps

Trigger request

A user or external system starts a defined job from the Catalog.

Validate rules

addy validates permissions, parameters, and execution context.

Execute via POD

The POD runs the job inside your internal network and processes the result.

Trace the result

Status, output, and requests stay documented and reproducible.

Transparency instead of appliance magic

You define which Jobs are available in the Catalog, which parameters are allowed, and which Endpoints are used. The POD only executes what you define.

Du kannst alles nachvollziehen. Du hast die Macht.