PKGi PS3: installing PS3 packages without a PC

A PSVita project ported to PS3, running on the console itself

PKGi PS3 is a PlayStation 3 port of pkgi for the PSVita, and the app it produces is a homebrew application for downloading and installing .pkg files directly on the PS3. The homepage is bucanero.com.ar, the licence is GPL-2.0, and the last push to the master branch was on 2026-10-17, with v1.3.0 published on 2025-12-20 and v1.2.4 back in January 2023.

The feature list is short and every item is about not needing anything else.

It is easy to use, with a list of available downloads including searching, filtering and sorting. It is standalone, meaning no PC is required and everything happens directly on the PS3. Downloads are automatic, since you choose an item and it is downloaded to the hard disk in direct mode, or queued for background download using the console's internal Download Manager. Interrupted downloads resume, so you can stop a download, switch applications and come back to it later.

Then there are two features that go beyond a downloader. Content activation generates .rif files for downloaded content, and the system must be activated for that. Content updates means the app can check online for available content updates.

Localisation covers Finnish, French, German, Italian, Polish, Portuguese, Spanish and Turkish.

Two notes in the README are worth keeping in mind, because they are behavioural limits rather than features. Queuing up multiple downloads is only supported in background download mode, and background download tasks only show up after you reboot the PS3.

The database you write is the catalogue

There is no built-in list of downloadable content. You create it.

The setup instruction is to create a pkgi.txt file in /dev_hdd0/game/NP00PKGI3/USRDIR containing the items available for installation, and the text database format is user customizable. The default format is a simple CSV where each line is one item:

contentid,type,name,description,rap,url,size,checksum

Each column has a defined meaning. The contentid is the full content id of the item, for example UP0000-NPXX99999_00-0000112223333000. The type is a number for the content type, set to 0 if unknown. The name and description are strings and cannot contain newlines or commas, which is a real constraint on any list you generate from scraped data.

The rap column holds the 16 hex bytes for a RAP file if the item needs one, and the .rap files are created on /dev_hdd0/exdata. Leaving it empty skips the file. The url is the HTTP, HTTPS, FTP or FTPS address of the .pkg file. The size is the size in bytes or 0 if unknown, and the checksum is a SHA256 digest as 32 hex bytes to make sure the file was not tampered with, and leaving it empty skips the check.

The sample file shows real entries, with the type, a name, a short description, a download URL, a byte size and a checksum for each. The type column is what decides where an item appears, with the values running from 0 for unknown through game, DLC, theme, avatar, demo, update and emulator, to 8 for an application and 9 for a tool.

Multiple database files, each auto categorised

Beyond the main pkgi.txt, the app can load additional database files, and the list names them all: pkgi_games.txt, pkgi_dlcs.txt, pkgi_themes.txt, pkgi_avatars.txt, pkgi_demos.txt, pkgi_updates.txt, pkgi_emulators.txt, pkgi_apps.txt and pkgi_tools.txt.

The behaviour is automatic. Items on each of these files are auto-categorized to the file content type, and the note in the README is that the app assumes every database file has the same format as defined in dbformat.txt. That assumption is what makes the split practical: you can drop a games list and a tools list into the same folder and the app will sort them into the right menus without you having to encode the category per line.

The content type table ties the numeric type value to the database file it belongs in. Type 0 is unknown, 1 is a game, 2 is DLC, 3 is a theme, 4 is an avatar, 5 is a demo, 6 is an update, 7 is an emulator, 8 is an application and 9 is a tool.

That table is also the reason the type column exists separately from the filename. A games file whose entries all carry type 1 is consistent, and a mismatch puts an item in a menu the user does not expect. For anyone scripting a list generator, that is the field to get right.

Online database refresh, and the Refresh menu entry

The databases can be kept current over the network, and the mechanism is a URL list in a config.txt file in the same USRDIR folder.

The example is three lines:

url http://www.mysite.com/mylist.csv
url_demos http://www.demos.com/otherlist.csv
url_emulators http://www.example.com/emulators.csv

The URL prefix determines which local file is refreshed. The README states that with this setup, pkgi.txt is updated with mylist.csv, pgi_demos.txt with otherlist.csv, and pkgi_emulators.txt with emulators.csv.

The next time you open the app you get an additional menu option, shown as a triangle icon, called Refresh, and selecting it synchronises the local databases with the defined URLs.

This is the practical answer to the maintenance problem with a hand-written catalogue. You can keep the list on a web server, update it whenever you want, and have every console with the app pull the new version. The cost is that the console trusts whatever the URL serves, which is why the checksum column in the database exists as a separate defence for the packages themselves, and why a plain HTTP url in the example is worth replacing with HTTPS in a real setup.

A custom format for databases that are not CSV

If the CSV convention does not fit your data, there is a second mechanism.

To use a custom database format you create a dbformat.txt file in /dev_hdd0/game/NP00PKGI3/USRDIR. The definition file is two lines of text. The first line is the custom delimiter character, with the examples given being a semicolon, a comma or a pipe. The second line is the column names for every column in the custom database, delimited by the delimiter defined in the first line.

The note for the columns is that, to be properly recognised, you must use the column tag names defined in the default format table, so contentid, type, name, description, rap, url, size and checksum. And all the columns are optional, so a custom database might have more or fewer columns than the default.

This is a reasonable design for a database format that a community maintains, because the delimiter choice and the column order are the two things that vary in practice, and both are handled without touching the code. The optional columns mean a minimal list of just a name and a url is possible.

The build system is the other place the customisation shows. The Makefile expects a PSL1GHT environment variable and errors out with a message asking you to set it if it is empty, then includes the ppu_rules from that path. The output identity is fixed in the Makefile, with the title PKGi PS3, the app id NP00PKGI3, a content id built from that app id, an icon at pkgfiles/ICON0.PNG and sfo.xml for the package metadata. The Makefile also has a Dockerfile and a Makefile.docker for building inside a container, and the container image is an Ubuntu 22.04 build that installs the PS3 toolchain, ya2d and mini18n from their own repositories.

Editorial conclusion

Adopt PKGi PS3 if you install PS3 homebrew on the console itself rather than pushing packages from a PC, because the whole point is that a download, a checksum check and an install happen on the device with no other machine involved. Do not adopt it expecting commercial content to work, since the content activation step depends on an activated system and the tool is aimed at homebrew packages. Before you set it up, read the database format documentation, because you have to author the pkgi.txt file yourself, and check that the item type numbers and the column names match what the build expects, since a mislabelled type changes which menu an item lands in.

Frequently asked questions

Official sources

1. bucanero/pkgi-ps3 on GitHub
2. License: GPL-2.0
3. Project website
4. README
5. Releases