Best practice for publishing Chromium as a single application in ThinLinc?

[Cagatay_Aydin]

Hi,

I’m evaluating ThinLinc for a small centralized browser-testing environment.

The goal is for each user to connect through either the native ThinLinc client or Web Access and receive only a Chromium window, rather than a complete Linux desktop.

The browser would be used to test interactive public web applications. This is one of the pages I’m currently using as the reproducible workload:

[REDACTED]

The page includes date and number inputs, JavaScript-generated results, CSS transitions, dynamically revealed content, and links that open external sharing services.

Disclosure: I help maintain the linked website. I’m including it only to show the actual application and interactions being tested.

I’m trying to determine the cleanest ThinLinc architecture for this setup.

1. Dedicated profile or “Start a program”?

Would you recommend creating a dedicated ThinLinc profile that launches Chromium, or using the client-side Start a program option?

The users should not see a normal desktop, application menu, file manager, or terminal.

2. What should happen when Chromium closes?

Ideally, closing the browser should either:

• End the ThinLinc session completely, or

• Restart Chromium automatically

I would prefer not to leave users connected to an empty desktop or background session. Is there a recommended session wrapper or profile configuration for this?

3. Persistent but isolated browser profiles

Each user needs a separate Chromium profile so that cookies, local storage, cache, and form state are never shared between accounts.

At the same time, I would like the user’s browser state to survive a temporary ThinLinc disconnection and remain available when the same session is reconnected.

Is using the user’s normal home directory sufficient, or is it better to assign a dedicated Chromium data directory for this type of ThinLinc profile?

4. Locking down browser access

For this environment, users should not be able to:

• Open local files

• Launch other Linux applications

• Access the server filesystem

• Install browser extensions

• Download executable files

• Use arbitrary external protocol handlers

Would you normally handle this through Chromium enterprise policies, Linux permissions, ThinLinc configuration, or a combination of all three?

5. Web Access versus the native client

The page contains lightweight CSS transforms and animations, but no video or 3D content.

Should standard software rendering normally be sufficient for this type of browser workload, or could Chromium still benefit from VirtualGL when several concurrent users are active?

I’m also interested in whether the native client would provide noticeably better responsiveness than Web Access for form-heavy browser applications.

Has anyone implemented a similar single-browser or browser-isolation setup with ThinLinc? I would appreciate any profile examples or configuration recommendations.

[aaron]

Hi @Cagatay_Aydin,

Yes, the single application publishing feature of ThinLinc sounds like it would suit your needs perfectly. In case you haven’t seen it yet, we have an overview of this feature here:

Does ThinLinc support publishing single applications as well as desktops?

This article introduces publishing single applications with ThinLinc, and discusses some of the benefits and limitations of doing so. Introduction Each ThinLinc session is built around a server-side process called Xvnc. Xvnc is the main process in any ThinLinc session, and is essentially an X server and VNC server combined. Applications publish their graphical output to Xvnc just as they would to a normal X server, but instead of ending up on a physical screen, it gets translated into the VNC p…

To answer your specific questions:

@Cagatay_Aydin

1. Dedicated profile or “Start a program”?

Usually it is better to set up a dedicated single-app profile. This process is outlined here:

Running a single app using ThinLinc

Sometimes you don't need to run a complete desktop in your ThinLinc session. In that case, you can run a single application instead. This tutorial shows three ways to set up ThinLinc to run just one program instead of an entire desktop. It is assumed that the ThinLinc server and client are installed and configured before starting this guide. To be able to run an application with ThinLinc, the application needs to be installed on the same machine as the ThinLinc server.   Configuration using …

@Cagatay_Aydin

2. What should happen when Chromium closes?

When Chromium closes, provided it is the only application running in the session, the session will be ended completely.

@Cagatay_Aydin

3. Persistent but isolated browser profiles

The users’ home directory should be sufficient for this, provided each session has a unique username and home directory.

@Cagatay_Aydin

4. Locking down browser access

As discussed in the knowledge base articles linked above, tl-single-app will only start the application provided to it as an argument, nothing else. This means no taskbar, menus, or any other desktop environment components. This is generally sufficient to prevent users from accessing other applications or files.

Regarding installing browser extensions, downloads, protocol handlers, file associations, etc, this would need to be configured via Chromium policies.

@Cagatay_Aydin

5. Web Access versus the native client

Assuming you don’t require features like local drive export, printing, audio, etc, the browser client should be fine. You may find that the native client gives slightly better performance, but for the use-case you describe, the difference is probably negligable.

If you have a GPU available, you could try using VirtualGL, but it may not be required for simple websites. One catch with VirtualGL is that while it’s possible to share a GPU across multiple users, it’s not possible to restrict how much of the GPU is available per user. So potentially, one user doing GPU-heavy work could affect the performance of other users on the server. So unless you really need it, it’s probably a good idea to test first without VirtualGL.

Hope that helps! Let us know how you get on with your evaluation.