Frequently asked questions about DevCaleo

DevCaleo is a central platform for shared test benches and engineering environments. Teams book systems, work on them via remote desktop and automate recurring tasks.

CI/CD pipelines execute automated tests. DevCaleo organizes the real hardware behind them: teams find shared benches, book them, and receive secure access. When a production or pipeline issue needs investigation on a HIL bench, authorized teams can reserve it and examine the issue in its technical context.

DevCaleo makes free capacity visible and improves the use of existing systems. Teams avoid duplicate setups, find benches and access faster, and release unused slots earlier. This reduces administrative effort and can reduce the need for additional test systems.

DevCaleo is designed for R&D teams, automotive engineering teams, test labs, universities, and technical organizations with shared engineering resources.

DevCaleo connects test benches, lab computers, HIL systems, development environments, ECUs, and remote access hosts. Booking windows, access, operational work, and automation remain connected to each resource.

DevCaleo brings platforms, test benches, lab computers, and accessories together in an integrated relational asset database. Teams can filter by technical attributes, availability, location, project, or ownership and keep resources and their relationships in view.

Yes. Resources can be organized by projects, groups, teams, or locations. Visibility and access depend on roles and permissions, so shared infrastructure can be made available beyond a single project where appropriate.

Usually no. DevCaleo is intended to connect existing test benches, lab computers, and development environments step by step. Existing systems remain in place and are provided through DevCaleo in a controlled way, similar to resources in a private on-premise cloud.

Yes. Authorized colleagues can be added to a booking and receive platform access for that time window. Depending on the configuration, they use a shared desktop view through Remote Desktop or WebRTC while SSH remains available for technical work. DevCaleo controls and records permissions, time windows, and access paths separately.

Depending on the platform configuration, DevCaleo can provide access through SSH, RDP, web terminal, VS Code or other remote access paths. Access is tied to bookings, sessions, and permissions.

Yes. Existing test benches, lab computers, workflows, scripts, and toolchains can be connected to DevCaleo step by step. The lab setup remains in place while teams book, use, and automate existing systems through one shared platform.

Yes. DevCaleo can automate repeatable operational tasks such as setup, checks, test execution, cleanup, and post-booking actions.

DevCaleo provides a runner for the target platform. It connects that platform to booking, access, and automation. Setup depends on the operating system and available prerequisites.

Yes. Depending on the setup and permissions, DevCaleo can provide AI-assisted features such as a chatbot for information, platform context, and operational data.

DevCaleo can run in Azure, AWS, or Google Cloud, as well as self-hosted or on-premise. The target environment follows network boundaries, security requirements, and the location of connected test systems.

DevCaleo stores the information needed for booking, access, and operations: users, roles, resources, sessions, tickets, workflows, and audit records. In a self-hosted or on-premise setup, this data stays in the customer's environment. Access is time-bound and relevant actions are recorded.

Yes. DevCaleo records security-relevant and operational events in an immutable audit history. Entries are linked through SHA-256 hashes so later modification can be detected.

DevCaleo has global user and admin roles. Projects, groups, and platforms add scoped member and owner rights. Effective access combines the global role, ownership, memberships, and direct grants.

The exact setup depends on the deployment model. In general, DevCaleo needs defined connectivity between the platform, the connected runners, and the target resources. Firewall rules, DNS, remote access paths, and internal network boundaries are clarified during setup.

A pilot starts with a small number of selected resources, such as one test bench or lab computer. Booking rules, access, roles, and initial automations are configured together. The team then evaluates the setup in daily work.

DevCaleo supports Windows, Linux/Unix, and macOS, so different workstations, lab PCs, and development environments can be connected to one central platform.

A DevCaleo runner is installed on the target platform. It connects the platform to DevCaleo, applies booking and access rules, and executes configured automation steps. Required permissions depend on the actions that should be controlled on that platform.

Yes. Admins can configure rules for unused bookings or inactive sessions. After the defined time, DevCaleo can end access and release the resource again so limited platforms are not blocked unnecessarily.

Retention depends on the customer's configuration and compliance requirements. In self-hosted or on-premise deployments, retention rules can be aligned with internal policies.

Updates are planned according to the chosen deployment and operating model. In enterprise setups, update windows, rollout steps, and responsibilities are defined with the customer so the platform fits existing IT operations.