3.0.26

1. Hackable UI

With 3.0, you can customize the UI:

1. Customize the home page
2. Customize the CSS for the app page
3. Customize Terminal

1.1. Customizing Home

You can customize the home page by creating an index.ejs file.

1.2. Customizing App Page

The app page can be styled with a custom CSS

2. Error Screen

2.1. Blue Screen

When something goes wrong, no more "ENOENT file not found", but instead open a blue screen with an actual relevant error message

Breaks when there's an error in the shell

• /error: /
• /errno /
• but ignore /error:.*trition/

2.2. Shell Breakpoint API

Additional patterns can be specified when calling shell.run to:

1. break when certain pattern happens
2. ignore certain patterns even if they match error messages

---

3. UV

uv (https://github.com/astral-sh/uv) is included by default, so all uv commands can be used in pinokio shells.

The disk space deduplication feature to save disk space via fs.link works out of the box, even when using UV.

---

4. Disk Usage Display

One of the most frequently asked question is "how much disk space does this app take?"

4.0 now displays the disk space size each app occupies.

---

5. JSON API

• json.get
• json.set
• json.rm

5.1. json.get

load JSON from one or more file paths and assign to local variables.

{
	"method": "json.get",
	"params": {
		<key1>: <filepath1>,
		<key2>: <filepath2>
	}
}

Example:

{
	"run": [{
		"method": "json.get",
		"params": {
			"config": "config.json"
		}
	}, {
		"method": "shell.run",
		"params": {
			"message": "http-server -p {{local.config.port}}"
		}
	}]
}

1. First it assigns the contents of config.json to local.config
2. Then accesses it with {{local.config.port}}

5.2. json.set

set attributes of a JSON file

{
	"method": "json.set",
	"params": {
		<filepath1>: {
			<key_path1>: <value1>,
			<key_path2>: <value2>,
			...
		},
		<filepath2>: {
			<key_path1>: <value1>,
			<key_path2>: <value2>,
			...
		},
		...
	}
}

Where <key_path> is a dot (.) separated string, where each component can be:

• an array index
• a key in JSON

Example:

{
	"method": "json.set",
	"params": {
		"config.json": {
			"a": 1,
			"b": 2
		}
	}
}

If config.json doesn't exist:

creates config.json and sets its content:

{
	"a": 1,
	"b": 2
}

If config.json already existed with the following:

{
	"a": 0,
	"c": 3
}

The result will be:

{
	"a": 1,
	"b": 2,
	"c": 3
}

5.3. json.rm

removes attributes at keypaths:

{
	"method": "json.rm",
	"params": {
		<filepath1>: [<keypath1>, <keypath2>, ...],
		<filepath2>: [<keypath1>, <keypath2>, ...]
	}
}

Example:

if we start with config.json:

{
	"a": 1,
	"b": 2
}

if we run

{
	"method": "json.rm",
	"params": {
		"config.json": ["a"]
	}
}

The resulting config.json will be:

{
	"b": 2
}

---

6. Browser Automation

Playwright is included in Pinokio by default, and the API to playwright is exposed via kernel.playwright.

You can use this API to write Javascript code which can be controlled by Pinokio scripts, which means you now can not only launch apps, but also automatically interact with them via script.

Playwright and a Playwright firefox browser is now included in Pinokio, and can be used in javascript.

You can write a Javascript class, which then can be called from a script.

First, create a browser.js

// browser.js
class Browser {
  async open(req, ondata, kernel) {
    let { firefox } = kernel.playwright
    const browser = await firefox.launch({ headless: false, });
    const context = await browser.newContext({ viewport: null })
    const page = await context.newPage()
    await page.goto(req.params.url)
  }
}
module.exports = Browser

Now we can call this in a run.json script:

{
  "run": [{
    "uri": "browser.js",
    "method": "open",
    "params": {
      "url": "https://pinokio.computer"
    }
  }]
}

When you run this, this will launch a sandboxed Firefox browser and open https://pinokio.computer

---

7. App Setup Wizard

Every script now has an additional optional attribute called pre, which lets you express mandatory environment variables that need to be set before each script can run.

• If the environment variables are NOT set, it will display the wizard screen where the user can fill out the environment variables
• If the environment variables are set, the wizard screen will NOT show up, and automatically use the saved environment variable values.

Every script can specify a pre array to specify which environment variables to require before running the script.

{
	"pre": [{
		"env": <ENVIRONMENT VARIABLE NAME>,
		"description": <ENVIRONMENT VARIABLE DESCRIPTION>,
		"default": <Default value (optional)>
	}],
	"run": [{
		...
	}]
}

Behavior:

1. If the required environment variables are already set, the script just proceeds using those environment variables.
2. If at least one of the required environment variables are not set, the script does not proceed, and waits until the variables are filled out

envs variable

now the envs variable is accessible inside templates.

{
	"method": "json.set",
	"params": {
		"config.json": {
			"PATH": "{{envs.PATH}}"
		}
	}
}

Also, the envs variable automatically normalizes the environment variables to uppercased version for the variables whose keys were not uppercase.

For example, if only the Path variable was set, the envs variable will include not only the Path value, but also a duplicate version under PATH, resulting in both Path and PATH variables with an identical value.

---

8. Huggingface API

Pinokio now includes a script API that lets you fully interface with huggingface-cli via JSON-RPC calls.

Exposes a dedicated HF api:

{
	"method": "hf.download",
	"params": {
		"path": <executing folder path (default is the current path)>,
		"_": [<arg1>, <arg2>, ...],
		<kwarg1>: <val1>,
		<kwarg2>: <val2>,
		...
	}
}

Example:

{
	"method": "hf.download",
	"params": {
		"path": "app/models",
		"_": ["adept/fuyu-8b", "model-00001-of-00002.safetensors"],
		"local-dir": "fuyu"
	}
}

internally runs:

huggingface-cli download adept/fuyu-8b model-00001-of-00002.safetensors --local-dir fuyu

---

9. New FS API

9.1. fs.open

{
	"method": "fs.open",
	"params": {
		"path": "<filepath to open>",
		"mode": "open"|"view"
	}
}

• mode: "open": open the file
• mode: "view" : open file explorer

9.2. fs.cat

print the file content

{
	"method": "fs.cat",
	"params": {
		"path": "<file path to read from>"
	}
}

9.3. Open in file explorer via pinokio.js menu

Use the fs: "view" attribute to open in file explorer inside pinokio.js

{
	"menu": [{
		"text": "open folder",
		"href": "outputs",
		"fs": "view"
	}]
}

This is equivalent to "fs": true

{
	"menu": [{
		"text": "open folder",
		"href": "outputs",
		"fs": true
	}]
}

You can open the file itself (it will open with the default app)

{
	"menu": [{
		"text": "open folder",
		"href": "outputs",
		"fs": "open"
	}]
}

---

10. Misc

10.1. Port Fix

Previous bug where Pinokio could not launch if there's a web server running at port 80

• Do not generate dynamic menu items when in home page (only generate dynamically when you visit each app) (Only run config.menu() when an app loads)
• Mobile view fix (When loading via local sharing)
• Do not automatically merge all JSON files in a folder (Was not being used and was just causing bugs)

10.2. Mac Compatibility Support

All shells launch with PYTORCH_ENABLE_MPS_FALLBACK=1 by default, which automatically falls back to CPU when a specific torch feature is not available in MPS

10.3. File Deduplication Fix

fs.link had a bug caused by a PIP bug where sometimes the PIP version and the contents don't match.

In these cases, creating a virtual drive were buggy because the previous logic was to ignore same folders from the same version.

The fix is to overwrite the same folders from the same version instead of ignoring.

Memory Leak Fix

Previously when you shut down Pinokio before shutting down apps, some of the remaining app processes may stick around, causing issues such as:

1. Keep consuming memory even when they all should be shut down
2. Sometimes you get "uvicorn" related errors saying the process is still running (This is because when you closed Pinokio last time, the uvicorn server inside pinokio kept sticking around even though it should have been shut down along with Pinokio)
3. Sometimes you can't delete folders because the folders are locked. All because the process associated with those folders are still running

Basically this update is a critical fix if you want to use Pinokio in a stable way. No other features have been touched, just this bug fixed, so no reason not to upgrade.

2.14.3

use port from pinokiod

2.14.0

Windows 24H2

Pinokio finally supports Windows 24H2 (Windows Insider Preview Canary + Dev + Beta + Release Candidate). Microsoft will soon roll out Windows 24H2, which breaks how shells work, which breaks all shell manipulation methods in Pinokio.

With Pinokio 2.2.0, the shell engine has been updated to work correctly on 24H2. This is a REQUIRED update.

---

Open in File Explorer

You can open any files and folders in a file explorer by appending ?fs to any URI in the pinokio.js file. Example:

// pinokio.js
module.exports = {
  version: "2.1",
  title: "test",
  description: "description",
  menu: [{
    text: "Open app folder",
    href: "app?fs"
  }]
}

---

Navigation Buttons

Based on feedback, the back/forward navigation buttons are back. Now you can navigate back and forth between pages instead of having to go back to home and come back.

2.1.63

use port from pinokiod

2.1.59

use port from pinokiod

2.1.17

1. Editor mode

• Accessible under the "Files" tab
• Edit and save files
• Run scripts and see them execute on the side terminal
• Correctly save files under the /api folder instead of /_api

The editor mode was broken for a while but all fixed with this version

2. ENVIRONMENT Bug Fix

ENVIRONMENT files were incorrectly being generated when inheriting from the system ENVIRONMENT.

2.1.14

1. Much quicker loading when downloading an app

Previously when trying to download an app, there was a slight freeze of the UI before the download page is loaded. This was because it was checking whether the core modules have been already installed or not every time the download page loaded. This is unnecessary and just making the UX bad, so now it instead checks the core modules at launch, and the download page will load instantly.

BEFORE

AFTER

2. PINOKIO_SHARE_LOCAL_PORT

The Local Network Sharing feature is great but by default the local share proxy servers are started at random ports. Sometimes you may want to fix these ports instead of dynamically generated.

Now you can do this by setting the PINOKIO_SHARE_LOCAL_PORT environment variable inside each app's "Configure" page.

Or can set it through the "Share" page:

3. Delete apps from home

Now you can delete apps from Pinokio home with just a click of a button.

4. Blue Screen

Previously when something went wrong on Pinokio it would just freeze with a blank white screen, with no way of understanding what's gone wrong. Now when something goes wrong, Pinokio will displays a "blue screen", displaying the error messages.

5. ENVIRONMENT Inheritance

Now when you set a custom environment variable in the ~/pinokio/ENVIRONMENT file, whenever a new app is installed, the generated ENVIRONMENT file will inherit from the custom attributes in ~/pinokio/ENVIRONMENT.

For example, if you set PINOKIO_SHARE_CLOUDFLARE to true globally through ~/pinokio/ENVIRONMENT, every app folder will automatically inherit this value true (by default it's false)

6. Various Bug Fixes

Some people experienced a blank white screen when upgrading to the last version. Have fixed a couple of issues which probably has fixed this.

7. Port 80 or 42000

Prior to Pinokio 2.0, the default port used by Pinokio has been 42000. With 2.0 this has changed to port 80 (in order to make the URL shorter when using Pinokio in zero-click launch mode inside regular browsers).

However, some people run web servers on their machine (which use port 80), and this caused problems for these users. So with this release, Pinokio tries to use port 80 but if it's already occupied, it uses port 42000.

This should get rid of all the issues related to the port (This was another reason some people were experiencing the "blank white screen" crash)

2.0.4

update

2.0.1

Pinokio 2

Highlights:

1. Autonomous Scripts
2. Zero click launch
3. Customizable apps
4. Pinokio Public Node
5. One click stop
6. Gradio file system
7. Disposable apps
8. More Efficient Disk Space Usage
9. Bug fix
10. Community Features

Autonomous Scripts

With 2.0, Pinokio Scripts can automatically start WITHOUT the user having to click through menu items. This removes a lot of friction in user experience, as well as enabling a lot of interesting use cases optimized for AI. What does this mean?

1. Instead of having to click the menu buttons, you can program scripts so that simply opening an app will run the relevant script.
   1. For example, if an app is downloaded but hasn't been installed, run the install script.
   2. Or, if the app is already installed, automatically launch the app by running the start script.
2. This behavior can be defined in the pinokio.js file by setting the default: true for whichever menu item needs to be selected at any given time. Any menu item that's set as default: true will be automatically selected, and when a script is selected it runs.
   1. Because the menu function gets refreshed every time a script finishes a step, this means it is possible to check for certain condition and start a script when relevant.
   2. For example, check if an app install folder already exists, and if it exists, run the start script to launch the app. But if the app folder does not exist, run the install script instead.

Example:

module.exports = {
  "version": "2.0",
  "title": "Autostart",
  "menu": async (kernel, info) => {
    let installed = info.exists("app/env")
    if (installed) {
      // already installed, automatically run "start.json"
      return [{
        default: true,
        text: "start",
        href: "start.json",
      }, {
        text: "install",
        href: "install.json"
      }]
    } else {
      // not installed. run "install.json"
      return [{
        text: "start",
        href: "start.json",
      }, {
        default: true,
        text: "install",
        href: "install.json"
      }]
    }
  }]
}

Zero Click Launch

1 Click Launchers aren't cool. You know what's cool? 0 Click launchers.

Before 2.0

Previously, using apps in Pinokio meant:

1. Open Pinokio
2. Find the app you want to use
3. Click the app to visit the app page
4. Click the "start" button to start the app
5. After the app starts, click "web UI" to open the web app

See, this is not really a "1 click" experience, is it?

After 2.0, with Zero Click Launch

You can now use Pinokio apps with the following step:

1. Start typing a pinokio app name in your web browser address bar.
2. It will autocomplete the URL (assuming you've visited it before)
3. Just open the web page, and you're good to go.

No clicks, not even a need to open the Pinokio app. You can basically use the local Pinokio apps just like visiting online websites.

Here's how it works:

1. Instant Access: You should be able to open any app INSTANTLY simply by typing its name in a browser address bar.
   1. Simply start typing the app's name in any browser address bar, and it will autocomplete (if you have visited the app before).
2. Instant Launch: You shouldn't have to manually "launch" an app first just to use the app. Think about regular online websites, you simply visit a URL and the website is there. This should be the standard. No need to explicitly launch an app just to use.
   1. When an app is not already running, it will automatically launch when you visit it, and then present you the UI. All automatically. No clicks needed.
   2. If the app is already running, then it's instant access. It's almost like using a regular website.

1. Launch and Run

For example, here's what happens if you visit a Pinokio app that is NOT running yet:

Since the app is not running,

1. it first launches the app
2. and then automatically redirects to the Web UI.

There was NO clicks involved. The redirects were automatic.

2. Instant Run

And what if the app is ALREADY running? Then it works no different from visiting a regular online website. Here's an example where I start typing "stable diffusion web ui", and the browser autocompletes the URL and I visit the page, and it sends me directly the web app.

Customizable apps

Pinokio is a tool for the tinkerers and hobbyists. It should make it dead simple for people to customize WITHOUT having to touch the code.

However this has not been easy. Until now, Pinokio didn't provide an easy way for end users to tinker with custom settings. For example if you want to change where files are stored, you had to edit the pinokio script code.

Pinokio 2.0 introduces ENVIRONMENT variables. Scripts can make use of environment variables instead of having to hardcode everything. Each app can have a custom environment variable file.

1. Template

You can define environment variables by simply updating a file named ENVIRONMENT (which is automatically created when you first install any script). Here's an example ENVIRONMENT file:

CHECKPOINT_PATH=./models/llama3.gguf

Pinokio scripts may use the variable simply by accessing the env variable:

{
  "run": [{
    "method": "shell.run",
    "params": {
	  "message": "./llama-server -m {{env.CHECKPOINT_PATH}}",
	  "path": "llamacpp"
	}
  }]
}

2. Sandboxed Environment Variables

Normally, setting environment variables require people to change it globally. This is not flexible since every app may have different requirements and you probably want a custom environment for each app.

Thanks to Pinokio's isolated architecture, every value set in each app's ENVIRONMENT file is constrained only to the app.

3. Friendly Interface

The built-in editor lets you tweak environment variables without touching the files directly. You can access the ENVIRONMENT editor interface inside the Configure tab in every app.

4. Custom Installer

Every app has a custom install page where the user can tweak the default settings BEFORE installing anything, such as changing the file folders, share settings, etc.

Pinokio Public Node

Now you can open up local Pinokio apps to the public internet.

1. Turn your local computer into a public web service

Anyone with a browser can connect to your local machine and run the apps you publish as public, powered by Cloudflare tunnel.

1. Run an AI inference service from your local computer, which anyone can access.
2. Keep your pinokio running at home and connect to it from outside using any device (such as phones)

2. Add authentication

Often you will want to only expose your public node to a select group of people. To achieve this, you can add authentication, which will require any user trying to connect to enter a correct passcode.

Turning on authentication is as easy as setting a "passcode" from the share settings page.

When you add authentication, you will be able to monitor all the incoming connections, from their IP to the device & browser information as well as which passcode is being used to make the connection.

Instantly Stop Scripts

When running things locally, stopping an app is as important as starting one, because most personal computers have limited resources and you can't be running all apps at once, and have to optimize your resources.

Before: Stopping an app wasn't easy. You had to visit the app page, open the app terminal, and click stop once the terminal loaded. Too many clicks.

After: you can stop any app with one click, either from home, or from the tabs.

Gradio File System

• Application File System: all files uploaded through gradio are now stored under the app folder (inside a folder named 'cache') instead of getting stored in an unknown location. Now you can view and manage all your files generated from gradio apps.
• Customizable: You can also switch the mode so all the gradio related files across multiple apps are stored deduplicated in one location, by setting the GRADIO_TEMP_DIR environment variable.
• Cross-app file sharing: Gradio has a security policy that blocks apps from serving files that are outside of each app's folder. For example, all the image files generated by automatic1111 stable diffusion web ui cannot be served by another app (for example a 3rd party app that serves the image files). This is for security reasons. With Pinokio, since everything happens inside pinokio anyway, Pinokio can expand this policy a bit and allow any app within the Pinokio operating system to be shared with any other app.

Disposable Apps

• Disposable Mode Install: Previously, if you install an app that uses torch hub files or any file from huggingface (for example through diffusers, transformers, etc.), all these files were stored in a single central location in order to save disk space. While this is ideal in many cases, a lot of times you just want to try an app and when you're done, just delete it, and want all the associated files to be deleted together. This was not possible before, but with 2.0, this is the default option when installing apps. Now every app install is self-contained by default, so when you delete the app folder, all the huge files associated with it will be gone with the app.
• Disk Space Save Mode Install: By default, all apps install in a disposable mode. But you can even customize this behavior and let Pinokio store these files globally in a deduplicated manner. This will be useful when you try out an app and decide to keep it. If you think you may want to keep using the app, you may want to reinstal...