Traceable
Every run is documented with parameters, output, and status in the Request log.
admins buddy | addy
Automate IT - without losing control.
addy turns PowerShell automation into repeatable services: with Catalog, Requests, approvals, and a complete execution history - directly in your infrastructure.
POD = execution node in your network (runs PowerShell; Endpoints stay internal).
Principles
- PowerShell-first: Reuse existing scripts and make them production-ready.
- Integration over replacement: Orchestrate deliberately instead of replacing platforms blindly.
- Transparency over black box: Every step remains reviewable and repeatable.
Why teams start with addy
You stay in control.
What you notice first in daily operations
Team-ready
Colleagues trigger services without direct script access.
Infrastructure-close
Execution runs in your network, close to AD, DNS, vCenter, and CA.
Architecture at a glance
After trigger, every step runs in a defined and repeatable sequence.
Define Jobs and parameters as a clear service.
Trigger Requests in a controlled way via web or REST API.
POD executes PowerShell automation inside your network.
Target systems stay integrated and traceable.
Operational control instead of script silos
Catalog, Library, POD, and Endpoints work together cleanly.
Catalog and Library as your service layer
- Jobs, parameters, and approvals are managed centrally.
- Reusable blocks are versioned in the Library.
- Teams trigger approved Requests without direct script access.
POD and Endpoints stay in your infrastructure
- Execution stays inside your own network close to your Endpoints.
- Systems like AD, DNS/DHCP, vCenter, or CA remain integrated.
- You do not blindly replace platforms, you orchestrate deliberately.
Typical starting points
Concrete use cases for daily operations
Start pragmatically, then scale step by step.
AD onboarding
Standardized, documented, and with less rework.
DNS A records
Reproducible instead of "quick manual changes in a tool".
VM snapshots
Maintenance and rollback as a defined service.
PKI Requests
Roll out certificates in a controlled way, with proof.
Operational impact
What improves concretely
-
Fewer follow-up questions because parameters and outcomes are documented.
-
Fewer errors because Jobs run standardized and versioned.
-
Faster throughput because Requests become self-service capable.
-
Better handovers because Request logs complement runbooks.
-
Audit-ready operation because every execution is traceable.
Next step
Start with one clear first workflow
Begin with a use case like AD onboarding, DNS A record, or VM snapshot. Once the flow is stable, move additional recurring tasks into the Catalog.
- AD onboarding
- DNS A records
- VM snapshots
- PKI Requests