On-premise · For engineering and R&D teams

One place to publish, share and manage your team's internal Python apps.

Your engineers and scientists already build web apps in Python. Toolship lets them share those apps with colleagues, with no deployment work. It runs on your own servers.

Get a walkthrough → What it does
  • Streamlit
  • Dash
  • Flask
  • FastAPI
  • More on request
The toolship portal listing a team's applications, each with its owner, a description and an Open button
One application's page: its address, version, source, owner and access, its usage over 30 days and its recent publishes

Why now

AI made building apps fast. Sharing them hasn't caught up.

A sizing tool, a model, a dashboard over test data: engineers and scientists now build working Python apps in days, and every team has more of them each month. Most never reach the colleagues who need them.

  • Nobody knows which tools exist, who owns them, or which version people use.

  • The app runs on its author's laptop or a server only they understand, and leaves when they do.

  • Colleagues get a script and an install guide, and give up.

  • Apps built in days get passed around with nobody checking who can open them or what they depend on.

What it does today

From the author's laptop to every colleague's browser

1

Publish an app in minutes

Publish a folder with one command, or connect a Git repository and branch and click Publish. Toolship installs the dependencies, builds the app and starts it at its own address.

  • Streamlit, Dash, Flask and FastAPI apps, and static sites
  • Dependencies from requirements.txt, pyproject.toml or uv.lock
  • No Dockerfile to write and no server to set up
2

Keep it up to date and under control

Each app has an owner, a version history and its own access rules.

  • Publish updates from Git, with every version and its commit kept in the history
  • A failed publish leaves the current version running, with build and app logs to see why
  • Choose who can open it: just you, named groups, or everyone signed in
  • Secrets and persistent data that carry over to new versions
  • Python dependencies checked for known vulnerabilities
An application page in toolship showing its address, current version, dependency check, source, owner and access
3

Know what exists, and who owns it

Colleagues find the tools they need in one portal. Administrators see every app with its owner, version and last publish, so a tool doesn't disappear with its author.

  • Hand an app over to a new owner when someone moves on
  • A searchable portal of the apps each person can open
  • Page views and visitors for each app, to see what is actually used
The list of every application in toolship, with its framework, status, version, owner and last publish

For IT

Runs on your servers, next to your tools

Toolship is installed inside your network, next to your GitLab or any Git server. It publishes from the branch you choose and records the exact commit.

One Linux server

One Linux machine with Docker. No Kubernetes, no cloud account, and nothing to install on colleagues' machines.

Your company login

People sign in with your SSO (Entra ID, Okta or any OIDC provider). Every app is behind sign-in.

You decide who publishes

Only people an administrator allows can publish, and every app has a named owner and access rules.

From the founder

Why I'm building toolship

Hi, I'm Julien, a senior software engineer at CEA, a French public research organisation. In 2022, my team and I built a small platform for our own apps. Today, more than 300 colleagues use it.

Then engineers and scientists started coming to us with apps they'd built in a few days with AI. Our platform was made for developers, and they had no simple way to share their apps. That's why I'm building toolship.

Building the app has become the easy part. I want sharing and managing it to be just as easy.

Julien Capul

Julien Capul, founder

julien@toolship.dev

Where it's going · Exploring

From publishing apps to a record of your technical computing

Toolship is young, and the roadmap is being shaped with the teams using it. Three directions I'm exploring:

Builders and users, connected

Every app already has a named owner. Next: users send bug reports, feature requests and feedback from the app's page, straight to that owner.

One interface over your compute

Launch long-running jobs (simulations, optimizations, parameter sweeps) on your VMs, GPU nodes, Kubernetes or Slurm and PBS clusters, without learning each scheduler.

Provenance and reproducibility

Each run records its app version, commit, environment, inputs and machine, so you can trace a result back and rerun it under the same conditions.

Have a use case that should shape what comes next? Let's talk.

FAQ

Questions about toolship

Streamlit, Dash, Flask and FastAPI apps, and static sites. Other Python frameworks are on request. Notebooks can be shared with JupyterLite, built as a static site: they run in your colleagues' browsers. To turn one into a full app, a few lines of Streamlit or Dash are often enough, and we can look at yours together during the walkthrough.

No. You say which framework your app uses; toolship writes the build and launch settings for you.

On a shared server, publishing an app is a software engineer's job: SSH, a Python environment, a service that keeps it running, a reverse proxy, a certificate, a login, and updates that don't break it. Most engineers who write the tools have never done it, so it falls to one person. With toolship, any engineer you allow publishes from a folder or a Git repository in minutes. The app gets its own address behind your company login, restarts if it crashes, and a failed update never replaces the version people are using. And every app has an owner, a history and access rules, in one place.

One Linux server with Docker (Windows servers are not supported), two DNS names (one for toolship, a wildcard for the apps) and a TLS certificate for them. No Kubernetes, and nothing to install on your colleagues' machines. I can do the first installation with you.

Your code, data and apps stay on your server, and toolship never calls home. To build apps, the server needs to reach a container registry and PyPI, and the dependency check sends package names and versions to PyPI.

Toolship is built for apps written by your own teams, with or without AI help, and only people an administrator allows can publish. Each version's Python packages are checked against public vulnerability databases, and known issues are flagged to the owner and administrators. It supports your own security review rather than replacing it, and it is not a sandbox for untrusted code.

Toolship is young, and a few things stay on your side for now. Its data is backed up with your usual tools, following a short documented procedure. It runs on one server, so apps pause while toolship restarts or is upgraded. Builds reach the container registry and PyPI directly, without a proxy or private mirror, and apps don't receive the signed-in person's name. Tell me which of these matter to you: they shape what comes next.

There is no list price yet. Early teams start with a pilot, priced together: we agree on what success looks like, I help you get your first apps running, and at the end you decide whether to continue.

Yes. I'm opening it to a small number of engineering teams, and I work closely with each one, so their needs shape what comes next.

See it on your own apps

30 minutes with me, no slides, no preparation. I publish an app in front of you, then we see whether it fits your setup.

Get a walkthrough →

Rather write? Email me at julien@toolship.dev.

Not ready yet? Get an email when something important ships.

Used only for toolship updates and my replies. No unrelated marketing. Privacy Policy.