How applications work
Applications in Nuvolos are software tools used to interact with data or code - JupyterLab, RStudio, VS Code, MATLAB, Stata, and many others. Nuvolos provides a curated selection of applications in commonly used configurations, so you can get started quickly. Custom configurations can also be set up. Any application that runs on Linux is supported, whether it is GUI-based, a web server, or a command-line tool.
For details on managing application settings, persistent storage locations, and shared mode, see Configuring applications.
Applications are always run within a particular Nuvolos instance. A given application can be run once, repeatedly, continuously, or multiple times in parallel. Applications are always containerised, meaning the tool and all of its dependencies are treated as a single whole (see below).
To run an application on Nuvolos, you must have at least the editor role in an instance.
Use Case: Streamlining Research and Coursework
Managing multiple software environments Researchers and students often struggle with installing, configuring, and maintaining different software environments - such as JupyterLab, RStudio, or MATLAB - across local machines. This leads to version conflicts, compatibility issues, and the "it works on my machine" problem, consuming time that should be spent on actual work.
Integrated, containerized applications Nuvolos provides a curated selection of containerized applications ready to use out-of-the-box. Users can instantly launch isolated tools directly within their cloud instances, with no local installation required. Because each application environment is fully containerized, different custom configurations can run concurrently without any cross-interference.
Increased productivity By eliminating environment setup, maintenance, and software distribution overhead, teams and classes can get straight to work. Seamless access and guaranteed reproducibility mean users spend less time on tooling and more time on their data, code, and collaboration.
Application containerisation
Every application in Nuvolos is containerized. Containerization bundles an application together with all of its configuration files, libraries, and dependencies. As a result, applications are isolated and independent of each other. This has several benefits:
Concurrent configurations - different configurations of the same Application can run side by side. You can have one JupyterLab with pandas 1.5 and another with pandas 2.2 in the same Instance, and changes in one do not affect the other.
Reproducibility - the functioning of the container is guaranteed. The same container produces the same behaviour, which is critical for scientific reproducibility.
Distributability - because the Application is a single self-contained unit, it can be distributed wholesale to other Instances along with all its packages, settings, and dependencies.
Snapshotting - Applications can be versioned with the same snapshot mechanism used for files and tables, captured as a single operation regardless of configuration complexity.
Initially, each Application contains the default configuration provided by Nuvolos. Once you start it, you can install new packages and libraries - those changes live inside the container and persist between restarts (within the Instance). Changing the configuration of one Application does not affect any others, including concurrent uses of the same Application type.
The Application lifecycle
Every interaction with an Application falls into one of four phases.
Configuration
When an Application is added to an Instance, it carries a default size, default settings, and default packages. Configuration changes - adjusting the inactivity limit, enabling shared mode, attaching add-ons, or changing the size - apply to all subsequent sessions of that Application. Most configuration changes take effect on the next restart.
Session
A session is a single continuous run of an Application. Every time you start an Application, Nuvolos creates a new session with a unique session identifier, allocates the requested resources from the resource pool, and starts the container.
A session is the unit of accounting: NCU consumption, Credit consumption, and log retention are all measured per session. The session history of an Application is preserved (with logs available for the last 7 days) so you can audit what ran when.
Auto-stop
Sessions do not run forever. Nuvolos automatically stops inactive Applications to allocate resources efficiently. Research and education spaces are handled differently:
In research spaces, an Application is considered active if it is opened and in focus in the browser, or if it is actively computing (using more than half of a single virtual CPU). Default inactivity limits are 6 hours for included sizes and 1 hour for credit-based sizes. Space administrators can adjust the included-size limit between 1 and 24 hours.
In education spaces, the default inactivity limit for any Application is 1 hour. To keep an Application active, it must be in focus in the browser for more than one uninterrupted minute every hour.
Researchers can launch long-running computations and the Application keeps running while it is actively computing. If the computation finishes (whether by completion or error) and the Application is not opened on Nuvolos, it is auto-stopped. Capturing and saving output logs is therefore important - anything not written to disk before the Application stops is lost.
Stop
When an Application stops - whether explicitly, due to inactivity, or due to insufficient Credits - its container is destroyed. The Workspace, Personal, and Application library areas (all backed by persistent storage) survive; the ephemeral local storage and any unsaved in-memory state do not. The next session starts a fresh container that mounts the same persistent storage, so files and installed packages are preserved across sessions.
Application scaling
Application resources can be changed at any time. Each application runs in a size that determines its CPU, RAM, and (optionally) GPU allocation. Sizes fall into two categories with very different cost models:
Included sizes consume Nuvolos Compute Units (NCUs) and are part of your Nuvolos subscription. They run on shared infrastructure: an Application with 4 NCUs can use up to 4 vCPUs and 16 GB of RAM, but at peak load the actual share may be lower depending on what other users are doing.
Credit-based sizes consume Credits and run on dedicated nodes. CPU, RAM, and GPU are guaranteed exclusively for the Application regardless of other platform users. This is the path to high-end workloads - large memory, GPU acceleration, or HPC-style allocations.
You can scale an Application up for a demanding computation and back down afterwards. The cost model rewards this: a stopped Application costs nothing, and a smaller size costs less than a larger one. This is a different mental model from owning a workstation - you only pay for the resources you actually use, when you actually use them.
Application distribution and reuse
Because Applications are containerised, they can be distributed wholesale to other Instances. The Application - with all its configuration and dependencies - is sent to the target Instance and can then be run there exactly as in the source. For teaching, mass distribution delivers not just course material but the entire working environment to every student, ensuring everyone starts from the same configuration. Applications can also be exported as Docker images for use outside Nuvolos. This supports several patterns:
Students experimenting with course code on their own machines after the course has ended.
Authors sharing Applications for peer review or long-term archival.
Researchers running Applications across multiple infrastructures, such as HPC clusters that support Apptainer (formerly Singularity).
Exported images include your application configuration, installed packages, environment variables, and optionally your workspace files. For more details, see Exporting applications.
Add-ons and extended capabilities
Applications can be extended with add-ons - sidecar services that run alongside the main Application. This is how Nuvolos provides database servers (PostgreSQL, MongoDB, MariaDB, Redis, Neo4j, OpenSearch, PostGIS), remote storage mounts (SSHFS, SharePoint, Rclone for S3), and VPN connections (IPSec, Fortinet) without requiring users to install and manage these services themselves.
Add-ons share the lifecycle of the main Application: they start with the session, are billed as part of the session's NCU consumption, and stop when the session ends. The add-on tab in the Application configuration is where this is wired up.
Where to go next
For step-by-step instructions on running, configuring, and stopping Applications, see How-to › Starting an application.
For the full configuration reference (sizes, ports, persistence options, add-ons), see Reference › Applications.
For how snapshots capture an Application's full state, see Snapshots, distribution, and states.
Last updated
Was this helpful?