Deployment modes¶
The same software runs in three arrangements (paper Fig. 6, Fig. 6 · Deployment). They differ in where the browser, the server and the data are, and in who can reach the server. In all three, the browser receives only the vectors on screen and the server reads only the chunks it needs, so the data never have to be copied to the viewer’s machine.
Desktop app |
Personal server |
Lab server |
|
|---|---|---|---|
Who uses it |
one person |
one person |
a lab or institute |
Where the server runs |
your laptop |
a workstation or HPC node next to the data |
an institutional server |
How you start it |
open the app |
|
gunicorn with the hosted WSGI factory, as a service |
How the browser reaches it |
inside the app |
SSH tunnel to |
HTTPS through a reverse proxy |
Login |
off |
off (the server is bound to loopback) |
on |
Which paths can be opened |
any on your disk |
any the server process can read |
only the data directory and |
Remote stores ( |
not supported (the app ships without the remote readers) |
allowed on loopback without login; with login only from |
only from |
Panel sets |
yours |
yours |
shared by all users, with owners |
Set-up page |
Choosing¶
Data on your laptop, only you. Desktop app, or
annzarro startif you have Python.Data on a cluster or a big workstation, only you. Personal server. The stores stay where they are; only the vectors you look at cross the SSH connection.
Several people should browse the same processed datasets. Lab server. It is read-only by design: it never writes to datasets and never runs user code, so giving a colleague access to a dataset does not give them write or compute access. The one thing users write is panel sets.