Blue SeagullGroup

Infrastructure and software systems

How Laridae works

Software streaming, built for work that punishes a laptop. The application runs on a cloud workstation and you work in its real interface from wherever you are.

1. The session path

When you start a session, the application opens on a cloud workstation with its own runtime, processing, storage, and access control.

What reaches you is the picture: the interface, streamed live. What goes back is your input, meaning the mouse, keyboard, pen, and the peripherals your work depends on.1

Because the work stays out there, so do the project files, the licences, and the hardware you would otherwise have to buy. The machine in front of you needs to show a picture and send your clicks.

The session pathYour application runs in a remote environment with its own runtime, storage, and access control. The picture streams to your device in real time; your mouse, keyboard, and peripherals stream back. Nothing runs on your machine.

2. The requirements move to the session

The point of Laridae is that you reach demanding software from the hardware you already own.2

The workstation spec, the graphics question, and the storage question belong to the environment now rather than to every desk.

That changes how you plan. Instead of sizing every machine for the heaviest thing it might ever run, you size environments for workloads and reach them from ordinary devices.

It changes where the work lives too. Files stay in the environment under its access controls, which helps when reviewers, contractors, or a distributed team all need the same project without it leaving the boundary.

Where things sit

Application execution
Remote environment
Project files and state
Remote environment
Hardware requirements
Remote environment
Access control
Environment boundary
Display and input
Your device

3. What we validate

Laridae is being validated with early teams. We look at the things that decide whether streamed software is workable for you.

Validation criteria
Ref.CriterionQuestion
01Application behaviourDoes the application behave correctly in a remote session, including windows, dialogs, plugins, and file handling?
02Input fidelityDo your mouse, keyboard, tablet, and the peripherals a workflow leans on arrive faithfully at the session?
03How it feelsIs the round trip good enough for the way this specific work is done, whether that is modelling, review, or playback?
04Session stabilityDo long working sessions hold up across reconnects, network variation, and real project files?
05Licensing realityHow your existing licences, licence servers, and vendor terms map into remote environments.
06Fitting your processFile exchange, shared storage, and review handoffs, and how the environment sits inside the work you already have.

1.How it performs depends on the application, your workflow, your device, the network, the region, and how the session is configured. We do not claim zero latency or performance identical to a local machine.

2.Reaching a session from any device is the goal rather than a guarantee. Your actual experience depends on the device, browser, operating system, network, and the application's own requirements.

4. Bring your stack and we will walk it through

The architecture is open for technical review. We will take your people through the session path, the environment model, and the access model against your real software list and network.