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...

2.0.2

Pinokio 2

UPDATE: just made a minor update to fix a minor bug (local sharing for pinokio itself was broken. local sharing for each individual app installed through pinokio works fine). Install 2.0.3 instead if you're seeing this https://github.com/pinokiocomputer/pinokio/releases/tag/2.0.3

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. Install Screen
11. Community Features

1. 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?

Let's take a look at a quick example. You click exactly once at the beginning when you install, and Pinokio automatically runs install script, and then start script, all without the user having to touch anything:

IMPORTANT

To take advantage of this new feature, in addition to updating to Pinokio 2, you MUST update each individual script, since these scripts have been updated to add the autostart features.

Now when you install something on Pinokio, you simply need to click Install and forget about it. And when you come back, you'll find that the app has been not only installed but already running, automatically.

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"
      }]
    }
  }]
}

2. Zero Click Launch

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

You don't even need to open Pinokio. You can open pinokio and its apps directly from a new web browser tab (In this example I'm opening Pinokio from my mac safari browser):

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 steps:

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 (to clarify, Pinokio itself should be running in the background, you just don't need to switch to Pinokio app itself like before, and instead just open apps directly from any web browser like Safari, Chrome, Firefox, Edge, etc.).

Basically, local apps work 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:

Notice how I start typing "Stable..." and it autocompletes "Stable Audio" since I have visited that URL before in the browser. Just select that URL just like you do with any online website, and it opens up Pinokio's Stable Audio app.

In this case, Stable Audio is not running when I entered the URL, so:

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.

3. 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. User 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.

3. 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.

4. 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, like this:

Then whenever someone visits the Cloudflare website, they will need to authenticate with a passcode, like this:

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 optimiz...