SWISH puts a sandboxed SWI-Prolog editor in a browser, and the local install is the interesting part

Three routes in, ordered by how much they cost you

The README opens with the choice set, and it lists three ways to use SWISH in increasing order of complexity.

The first is the online version at swish.swi-prolog.org for plain Prolog and R, with two further hosted instances: cplint.ml.unife.it for probabilistic and machine learning extensions, and the Logic Production Systems demo at lpsdemo.interprolog.com. The README says these servers can be used for playing, courses or sharing and discussing ideas, and that the project tries to keep the server continuously online.

The second is the Docker image, maintained at the swipl organisation on Docker Hub.

The third is a local installation, which is the one that involves real work.

The distinction that matters for choosing between them is persistence. The README is candid about the hosted version: they have not yet dealt with scalable hosting nor with really reliable and scalable storage for saved programs, and the hope is to keep all your programs online for at least multiple years. So the online version is excellent for teaching and demonstrations and unreliable as a system of record, which is a decision you should make before you start building a course on top of it.

The project is a SWI-Prolog subproject rather than a standalone product, the repository description calls it SWI-Prolog for SHaring, and the primary language is Prolog.

The Docker route, with the R service as an example

The Docker path is the shortest path to a private instance, and the README gives a worked example that also shows how the pieces fit together.

To run SWISH with R, you start a separate R service container and then start SWISH against it.

    docker run -d --net=none --name=rserve swipl/rserve
    docker run -d -p 3050:3050 --volumes-from rserve -v $(pwd):/data swipl/swish

The first container is deliberately isolated with --net=none and given a name, rserve. The second inherits its volumes with --volumes-from rserve, publishes port 3050 to the host, and mounts the current directory at /data. The result is a SWISH instance on http://localhost:3050 that can talk to the R service without the R service being reachable from the network.

That separation is the whole design in two lines. A language runtime such as R is a separate process with its own network exposure, and SWISH is what connects the browser to it.

The README notes that there are many configuration options for SWISH, notably for authentication, email notifications and extension plugins, and points at the docker-swish repository for details. That is the file to read if you want anything beyond the default, since the options are documented there rather than in this repository.

Assembling the local install from submodules, packs and Yarn

The local installation is where the real dependency list shows, and the README is unusually honest about the friction.

First, submodules.

    git submodule update --init

Then the packs, which are the SWI-Prolog pack repositories for extra libraries. You configure the desired ones by editing the PACKS variable in the Makefile and then run:

    make packs

The Makefile lists the default set as profile rserve_client smtp pcache sCASP, and the packs target downloads them and configures the ones that need configuring.

Next, the JavaScript dependencies. The preferred route is Yarn, installed on Ubuntu by getting node and npm first.

    sudo apt install npm nodejs
    sudo npm i yarn -g

Then from the top level of the swish checkout:

    yarn
    make src

The package.json declares yarn >= 1.0.0 and pins its dependencies by git reference, including codemirror, jquery, requirejs, bootstrap, vega and vega-lite, plus js-sha1 and tagmanager. The Makefile also has a min target that creates minimized CSS and JavaScript, and a clean target.

The fallback exists because, in the README's words, installing node and yarn is not a pleasure on all operating systems. You can download the dependencies as a single zip from the SWI-Prolog site and unpack it from the swish root to create web/node_modules, or let the Makefile do it with:

    make yarn-zip

The zip route avoids a JavaScript toolchain entirely, which is the reason it exists.

SWI-Prolog itself, and the version churn nobody warns you about

The dependency that is hardest to satisfy is SWI-Prolog, and the README explains why in unusually blunt terms.

You need the latest SWI-Prolog development version. Because SWISH is very much in flux and depends on the recent SWI-Prolog engines and sandboxing libraries, it is quite common that you need the nightly build for Windows or to build the system from the current git development repository swipl-devel.git.

That is a strong statement for a web IDE, and it has a direct consequence: you are not installing a released package, you are tracking a moving development build of the language implementation.

There is a dated note about how wide the range actually is. Apr 25, 2019: works for a quite large range of SWI-Prolog versions, with the swipl-devel.git state at that time fixing an issue in CSV downloading, emitting CORS and cache control HTTP headers near the end of the CSV output. The CORS detail is the one to remember, because a browser refuses a download whose response lacks the right headers, and that failure looks like a broken Prolog program rather than a server configuration issue.

Two optional system dependencies sit alongside. Rendering Prolog terms as graphs requires Graphviz, and the avatar system requires the convert utility from ImageMagick, both available as packages on Debian based systems.

    sudo apt-get install imagemagick
    sudo apt-get install graphviz

The last push to the repository was on 2026-06-17, the default branch is master, and the repository has no GitHub releases. The version is tracked in a VERSION file at the root.

Running it, and the two configuration files that decide your security posture

Starting SWISH is opening run.pl, either by running `swipl run.pl` on Unix or by opening run.pl from the Windows explorer. You then point your browser at http://localhost:3050/.

The configuration model is simple and worth understanding precisely, because it is where the security decision lives.

Configuration is done by reading `*.pl` files from the directory config-enabled. The directory config-available contains templates that can be copied and optionally edited to create a configuration, and there is a README.md in config-available with details.

By default, SWISH does not require the user to login but lets you run only safe commands. To use SWISH for unrestricted development, you enable the config file auth_http_always.pl by symlinking it into config-enabled.

    mkdir -p config-enabled
    (cd config-enabled && ln -s ../config-available/auth_http_always.pl)

There is a middle option too. Instead of auth_http_always.pl you can use auth_http.pl, which allows for unauthenticated sandboxed usage as well as logging in to the server and getting unrestricted access. For a shared instance on a network that is not fully trusted, that is the sensible configuration, and it is the one the README describes between the two extremes of sandboxed-anonymous and login-for-everything with full Prolog access.

The password file stores SHA1, and the traffic is not encrypted

The README documents the authentication weaknesses plainly, and this is the section to read before you expose an instance.

Authentication uses HTTP digest authentication by default. The method uses a challenge-response approach so that credentials change with every request and old credentials cannot be reused by an attacker. That part is sound.

The problem is on the storage side. The server stores the password as a SHA1 hash built from the user, the password and the authentication domain, and the README calls this relatively vulnerable to brute-force attacks for anyone who gains access to the password file, because of the low computational overhead of SHA1 and the lack of a user-specific salt.

The second problem is the transport. The exchanged commands and replies are not encrypted, so a secure server should use HTTPS.

Creating the first user is done with the swish_add_user/0 predicate, which asks for details and updates or creates a file called passwd. Group and E-Mail are stored but not used at the moment.

    ?- swish_add_user.
    % Password file: /home/jan/src/prolog/swish/passwd (update)
    User name: bob
    Real name: Bob Hacker
    Group:     user
    E-Mail:    [email protected]
    Password:
    (again):
    true.

The path in the output shows where the password file lands, next to the Prolog source rather than in a system directory, which is consistent with a tool that expects to be run from its own checkout.

Where SWISH is the wrong choice

Three cases argue against it.

The first is anything that needs its saved programs to be reliable. The hosted version's own README admits the storage is not scalable or reliable, and there is no versioning, no private repository and no backup story for a notebook you saved three months ago. A teaching tool that you use live in a lesson is a different proposition from a research notebook you depend on.

The second is a stable release of the language itself. Depending on a nightly build or a git development build of SWI-Prolog means your environment changes under you, and the README's own recommendation to use the development version is a statement about SWISH's relationship with its host language rather than a preference.

The third is a production service. SWISH is an IDE with a sandbox for untrusted code execution, an authentication layer with the weaknesses described above, and no encrypted transport by default. It is designed to be used by people experimenting with Prolog, not as a multi-tenant service exposing arbitrary Prolog execution to the internet.

The alternatives are worth being concrete about. For a course, a shared server on a university network with auth_http.pl gives anonymous sandboxed use plus login for staff, and needs nothing else. For a private team instance, the Docker image is the route, with the R service pattern showing how to keep language runtimes off the network. For a production Prolog API, none of this is the right shape: you would call SWI-Prolog directly as a library, with an HTTP framework you control, and write the sandboxing policy yourself.

Editorial conclusion

SWISH fits a Prolog teacher or student who wants to hand out a program as a link and let people run it in a browser, and it suits a team that wants a private instance for internal experiments. It does not fit a deployment where stored programs must survive a server rebuild, because the README states that scalable hosting and reliable scalable storage for saved programs have not been dealt with. Start from the Docker image at `swipl/swish` if you want a self-contained instance, and read the authentication section before enabling `auth_http_always.pl`, because the password file stores SHA1 hashes and the exchanged commands and replies are not encrypted.

Frequently asked questions

Official sources

1. Issues
2. README
3. SWI-Prolog/swish on GitHub