Frequently asked questions about DevCaleo

DevCaleo is a B2B software platform for booking, accessing, and automating shared engineering and test infrastructure.

DevCaleo combines access control, operational coordination and technical transparency in one platform. Reservations, sessions, tickets, workflows, test runs and assets remain connected in one traceable process.

DevCaleo helps companies use existing resources more effectively: teams find available platforms faster, avoid duplicate setups, book capacity more reliably, and release unused resources sooner. Operations and maintenance become easier to coordinate and automate, which reduces manual support effort and can reduce the need for additional platforms.

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

DevCaleo supports test benches and lab computers with clear booking windows, secure access during the approved period, Kanban, and workflow automation. It can also manage HIL systems, development environments, ECUs, remote access hosts, and other shared technical resources.

Yes. DevCaleo can be used to build an internal resource cloud for test benches, lab computers, and development environments. Depending on requirements, the platform runs hosted, self-hosted, or on-premise, with access, resources, and operational data kept in the defined enterprise environment.

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 operational data stays in the customer's environment. Access is time-bound and relevant actions remain traceable.

Yes. Existing test benches, lab computers, workflows, scripts, and toolchains can be connected as resources in DevCaleo. This creates an internal platform where teams can book, access, and automate existing systems without rebuilding the lab setup.

A pilot usually starts with a small number of selected resources, such as one test bench or lab computer. It builds the first slice of the internal resource cloud: booking rules, access, roles, and first automations are configured, then the team evaluates the fit in daily work.

Excel and calendars show reservations, but they do not operate the resource. DevCaleo connects booking, sessions, access, tickets, workflows, automation, and asset context. Existing test benches and lab computers become a controlled internal platform instead of a planning list.

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. DevCaleo can automate repeatable operational tasks such as setup, checks, test execution, cleanup, and post-booking actions.

Yes. DevCaleo can support AI-assisted features such as a chatbot that helps users find information, understand platform context, and work with operational data depending on the configured setup and permissions.

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

In the DevCaleo interface, teams can download a runner for the target platform in a few clicks. The runner controls bookings, access, and automation on that platform, and installation usually takes about one minute.

Yes. DevCaleo provides an enterprise overview for audit trails. Changes on connected platforms are logged transparently and protected with SHA-256.

Yes. A booking and the associated access can be shared so authorized users can access the platform for the duration of the booking.

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.

For each booking, DevCaleo creates an OTP, or one-time password. The operating system password for the booked platform is changed temporarily, and only the booking user or explicitly shared users receive access to the valid password.

DevCaleo distinguishes users, operators, and admins. Users book platforms, connect during approved time windows, share sessions, run workflows, and work with tickets or Kanban. Operators manage platforms and resources, review status and statistics, and coordinate workflows. Admins have project-wide visibility and manage roles, policies, integrations, and settings.

The catalog makes existing platforms, test benches, lab computers, and accessories searchable across projects or teams. Users can review technical details, availability, ownership, and access options before creating new setups.

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.

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.

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.

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.

Sharing is controlled through roles and permissions. A booking or session can be shared only with authorized users, and access remains limited to the approved time window and resource.

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.