Each scheduled run uses its own isolated environment. Previously, all scheduled notebooks shared the same environment. Now, each run creates a clean kernel that’s deleted afterward, reducing the chance of unintended breakages.

No more version constraints on package installs. You can install any version of a Python package, even if a different version was pre-installed.

Fewer default packages. Some packages previously included by default are no longer pre-installed unless needed by BlueConic.

paramiko

pandas

matplotlib

pytz

numpy

seaborn

sklearn

If a notebook uses (imports) packages that are not available out of the box, always install these packages explicitly in that notebook.

Always install one specific version of a package. Use the “==” to specify the version.

Try to use the latest versions of the packages. Old (4+ years old) versions may cause errors during installation and may also exhibit reduced performance.

Avoid manually (re-)installing packages that are installed by default from Blueconic (see the first table above). The reason to avoid this is that BlueConic may upgrade to a higher version in future releases. However, if you install an older version, it will remove the newer version that comes by default, possibly decreasing performance.

Do not uninstall the default packages (see the first table above). BlueConic needs these to run correctly.

BlueConic scheduled runs now use ‘uv pip install’ to install packages, instead of ‘pip install’. But BlueConic users who install packages should not use uv for manually installing packages. Although supported by Jupyter, BlueConic scheduled runs do not support these install lines. For stability, only use ‘%pip install….’ or ‘!pip install….’.

Never use “--force-reinstall”. Perhaps this was necessary in the previous version to install a package that was already present, but with scheduled runs, you start with a clean slate every time. In that case, “--force-reinstall” is redundant, but will be detrimental for performance and memory use later during the scheduled run.

Notebook runs use a Python interpreter to run the Python code. Within Jupyter notebooks, these are called ‘kernels’. Previously, we always used a single kernel for all runs. In this release, we create several kernels, used for different notebook runs. In edit mode, we use one kernel (called the edit mode kernel). When running a notebook via scheduling (or ‘run now’), a kernel is created for that single run. This kernel is deleted after the scheduled run has finished.

Previously, you could install Python packages within a notebook during a scheduled run. Once a package was installed during the first run, it remained available for subsequent runs, not just for that specific notebook, but for all scheduled notebooks. This remained true until the next BlueConic release, at which point the system running the notebooks was reset. After a reset, any previously installed packages must be reinstalled. With the current release, each scheduled run starts with a newly created, clean kernel environment. As a result, any packages installed during a previous run will not persist. Therefore, every scheduled notebook must explicitly install any required packages at the beginning of its execution—unless those packages are already included by default. Packages installed in Edit Mode will remain available for future Edit Mode sessions—this behavior has not changed. However, the kernel used in Edit Mode is now separate from the one used by the Jupyter server. As a result, if there's an issue (such as a faulty package installation), it may affect only the Edit Mode kernel without impacting the Jupyter server or scheduled runs. This isolation helps ensure greater stability across your environment.

Previously, any packages installed by BlueConic out of the box had a specific version, and it was not possible to install a different version. The reason for using constraints was to prevent potential conflicts between packages required by BlueConic and those needed by the user. With the current release, this is no longer the case. However, packages are still installed by default. Installing the same package with a different version will rarely conflict due to kernel isolation(see above) and can be fixed easily.

In previous versions, one notebook could break another notebook by installing incompatible packages. We’ve now improved isolation by creating a new virtual environment for each scheduled notebook run, which in turn should make notebooks more robust.

Yes, in order to run your AI Workbench notebook code as of June 2025, the packages used in your notebook code have to be installed by that notebook if not part of the table above.

These changes were made as part of the Q3-2025 release. Visit status.blueconic.com for current status updates for the BlueConic platform. This page is updated continually and announces major updates to the BlueConic platform

Any notebook using packages that it is not installed will not run successfully and will throw an error. Check the AI Workbench run history for your notebooks for errors.

The notebook run history will show an error: ERROR: ModuleNotFoundError: No module named 'pandas'

Existing notebooks will automatically use the new kernel. When you open the notebook, it will detect and display the correct (latest) kernel without requiring you to save or update anything manually.

Contact BlueConic Support if you have questions. Note that BlueConic Support cannot edit your AI notebooks but can help you understand if there are errors and how they should be resolved.