> For the complete documentation index, see [llms.txt](https://docs.nuvolos.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nuvolos.com/tutorials/tutorials-for-instructors/running-a-data-heavy-lab-session.md).

# Running a data-heavy lab session

<mark style="color:$primary;">**What you will achieve.**</mark> \
By the end of this tutorial you will have set up a course space with a configured application, prepared a dataset, distributed both to a cohort of students, and run through the workflow you would use during a live teaching session.

<mark style="color:$primary;">**How long it takes.**</mark> \
About 45–60 minutes the first time, depending on the size of your application image and dataset.

<mark style="color:$primary;">**What you need before you start.**</mark> \
You should have completed [Your first course on Nuvolos](/tutorials/tutorials-for-instructors/your-first-course-on-nuvolos.md) tutorial - that is, you have an organisation membership, you have created at least one course, and you understand the role of the Master instance. You should also have a sample dataset on your local machine (a CSV is enough) and a clear idea of which application image (for example, JupyterLab with Python, RStudio, or a Stata image) you want students to use.

{% stepper %}
{% step %}

### <mark style="color:$primary;">Step 1 - Create a course space dedicated to the lab</mark>

If you reuse a course from [Your first course on Nuvolos](/tutorials/tutorials-for-instructors/your-first-course-on-nuvolos.md) tutorial , you may end up mixing tutorial leftovers with real lab material. For this tutorial, create a fresh course.

From the Dashboard, select + NEW COURSE. Enter a name (for example, "Data Lab - pilot") and a description. Select + ADD SPACE.

When the application picker appears, do not skip it - choose the application you want students to use during the lab. Enter a name for it and select + INSTALL. Installing the application now means it is part of the Master instance from the start, ready to be distributed to every student.

{% hint style="info" %}
**Why this matters**

A data-heavy lab fails the moment one student is on Python 3.9 and the next on Python 3.11. Setting up the application centrally - once, in the Master instance - is the move that eliminates the "it works on my machine" problem entirely. Every student gets the exact same image.
{% endhint %}
{% endstep %}

{% step %}

### <mark style="color:$primary;">Step 2 - Configure the application</mark>

Open the Master instance and start the application you just installed. Install or configure anything the lab needs: extra Python packages, R libraries, connection strings, environment variables, helper scripts. Treat this like a one-time setup of a teaching laptop - but you only have to do it once, here, for everyone.

If the lab needs a GPU or unusual amount of memory, configure that on the application now. See [Application resources](/reference/applications/application-resources.md) in Reference for the available options. If your institution restricts GPU usage, your administrator may need to enable it for the space.

Stop the application when you are happy with the configuration. The configuration travels with the application when it is distributed.
{% endstep %}

{% step %}

### <mark style="color:$primary;">Step 3 - Add the dataset and lab notebook to the Master instance</mark>

Switch to the Files view in the Master instance. Upload your dataset and a starter notebook (or script) that students will edit during the lab. Keep the layout simple at this stage - flat is fine for a single lab session.

If your dataset is large or you want to use a database-backed approach instead of flat files, see [File storage](/reference/file-system-and-storage.md) and [Data storage](/reference/data-storage.md) in Reference.

Open the application again, run the starter notebook end-to-end, and confirm that everything works in the Master instance. The Master instance is your rehearsal stage - if it does not run cleanly here, it will not run cleanly for any student.
{% endstep %}

{% step %}

### <mark style="color:$primary;">Step 4 - Distribute everything to current and future students</mark>

Distribution sends teaching material to all current and future instances in your course. This means you can distribute to both existing and prospective students in one step. The mechanism is documented in detail under [Distribution](/how-to-guides/common-workflows/object-distribution.md); the steps below are the practical lab-session workflow.

1. From the Master instance, make sure you are in the Current state.
2. On the Files screen, select your dataset and starter notebook and click STAGE. Recently used applications are automatically added to the distribution; review them and remove any you don't want students to receive. Selecting a folder adds the entire file tree recursively, and any sub-folder structure is preserved.
3. On the sidebar, click the share icon to open the Stage. Review the staged objects and click CONTINUE.
4. (Optional) Save the staged objects as a named bundle for future reference. This is useful if you plan to run the same lab next term - you can re-distribute the bundle without rebuilding it.
5. Select the target. By default, you distribute to all students - every existing instance and every future instance.
6. Decide on notifications. Send a notification email with a custom message so students know new material is available - useful when the lab is the next morning and they need to confirm their environment in advance.
7. Select the [distribution strategy](/reference/configuration/distribution-strategies.md). Overwrite is the default and almost always the correct choice for a fresh lab.
8. Review the list and click SHARE OBJECTS. Distributing large applications can take a while to complete - start the distribution at least an hour before the session if your image is large.

{% hint style="success" %}
**Checkpoint**

If you have a test student account from Your first course on Nuvolos tutorial, sign in as that student now and confirm that the dataset, notebook, and application all appear in the student instance. Run the notebook end-to-end as the student would. This is the single best way to catch problems before a live session.
{% endhint %}
{% endstep %}

{% step %}

### <mark style="color:$primary;">Step 5 - Run the live session</mark>

During the session itself, your role inside Nuvolos is mostly to watch and support. Each student works in their own isolated instance - they cannot break each other's work, and they cannot break the Master instance. You can:

* Continue editing material in the Master instance and re-distribute fixes as needed (use Overwrite to push corrections live).
* Switch into student instances if a student gets stuck - Space Administrators have full visibility over every instance in the course.
* Use the same application as the students in your own instance to demonstrate steps in real time.

If something goes wrong with the material mid-session - a typo in the notebook, a missing file - fix it in the Master instance, stage just the fixed file, and re-distribute. Students who refresh will pick up the fix; students mid-flow will not have their work overwritten if they have already modified the file locally.
{% endstep %}

{% step %}

### <mark style="color:$primary;">Step 6 - Capture the session</mark>

After the session, take a snapshot of the Master instance. A snapshot freezes the exact state of files, code, and configuration at this moment, and you can return to it any time. This makes the session reproducible — for next term, for a student who missed it, or for a colleague who wants to see exactly what you ran. Snapshots are explained in [How snapshots and states work](/concepts/distribution.md) in Concepts.

{% hint style="success" %}
**You're done**

You have run a complete data-heavy lab cycle: configure once, distribute to everyone, watch students work in identical isolated environments, fix and re-distribute on the fly, and capture the result. The same pattern scales from a one-off lab to a full term-length course.
{% endhint %}
{% endstep %}
{% endstepper %}

#### Where to go next

* To repeat the same setup for a parallel section, see [How-to › Structure your course](/how-to-guides/workflows-for-instructors/best-practice-structuring-your-course.md).
* To turn the lab into a graded assignment, see [How-to › Assignments, grading, and feedback](/how-to-guides/workflows-for-instructors/setting-assignments.md).
* To run the lab on GPU-enabled machines, see [How-to › Courses with GPUs](/how-to-guides/workflows-for-instructors/courses-with-gpus.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nuvolos.com/tutorials/tutorials-for-instructors/running-a-data-heavy-lab-session.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
