LaunchPad banner

LaunchPad

3 devlogs
10h 17m 21s

LaunchPad is a panel and a daemon to interact with docker and easily deploy and manage containers for specific purposes. Trying to be a simple Pterodactyl Wings alternative.

This project uses AI

I used AI for debugging and fixing some docker and postgresql specific issues related to the code. I also used it to help making the frontend for the demo. I am sadly not a frontend guy and the shipwrights told me a demo would be nice.

Demo Repository

Loading README...

Bram (QKing)

Shipped this project!

I build a daemon for managing and running docker containers with a HTTP API. It is highly optimised and build in rust. Please read the previous devlogs and the readme for a lot more information. This project is for LockIn week 2.
The demo is selfhosted on my own systems, so please respect that.

Bram (QKing)

LaunchPad - Devlog #3

Hey! This is devlog 3, the last devlog before shipping. Sorry that it came so late, but there were some desyncing issues with FlavorTown/Hackatime. This devlog will mostly go about the demo.

What’s done so far:

I have made a copy of the daemon and I started slowly locking features. Since I want to provide a demo, but I have to selfhost it and I prefer to stay safe I had to do that. Features like deploying and deletion of containers are locked. You can still try the websocket shell. The demo is available at https://launchpad.qking.me. It is selfhosted by myself on my own homeserver.

I have also improved the .env loading and I have written a lot of documentation during the initial readme creation for the main project. I have also fixed some small bugs that I came across.

I sadly couldn’t make the panel, since I realised I am so bad at frontend that it wouldn’t be possible in this week of Lockin.

What’s next

Currently I have nothing planned. Week 3 (this is week 2) of Lockin will most likely be another project. I might start working on it in week 4 or I will work on it afterwards. I will make it eventually. For now, it will just be a daemon.

Till next time! (char limit)

Changelog

Attachment
0
Bram (QKing)

LaunchPad - Devlog #2

I have once again worked on the project
I have scanned the code on vulnerabilities with use of several scans and with help of ai.
I have patches those issues after it.
Also I have commented a bit more to clarify things in the code.
This devlog brings no new features.

What’s done so far:

As I said I patched several vulnerabilities. I listed them below.

Critical (2):
Hardcoded fallback API key in three separate locations (src/api/auth.rs, src/api/tokens.rs, src/api/websocket.rs, src/config/loader.rs, .env)

Path traversal + shell injection in file endpoints (src/api/files.rs)

High (5)

WebSocket shell auth via URL query param with key logged in access logs (src/api/websocket.rs, src/api/routes.rs)

Unrestricted Docker image pull with ImagePolicy never enforced (src/api/apps.rs, src/docker/policy.rs)

SSRF via unvalidated webhook URLs (src/api/webhooks.rs, src/api/apps.rs, src/api/power.rs)

App tokens stored and compared as plaintext (src/db/queries.rs, migrations/0002_extras.sql)

Wildcard CORS allowing any origin to make credentialed requests (src/main.rs)

Medium (5)

Signal injection via kill endpoint allowing arbitrary OS signal to any process (src/api/power.rs)

Port allocator state is in-memory only and not persisted across restarts (src/server/ports.rs, src/server/state.rs)

No rate limiting on any endpoint (src/main.rs, src/api/auth.rs)

Containers launched with default capabilities and no security hardening (src/docker/client.rs)

Port mappings added to database without rebinding Docker causing state desync (src/api/ports.rs, README.md)

Low (3)

App name unsanitised and used in Docker network names and host filesystem paths (src/api/apps.rs, src/api/network.rs)

Environment variables passed to containers without validation leading to potential secret leakage (src/api/apps.rs, src/docker/client.rs)

Timing side-channel in API key comparison (src/api/auth.rs, src/api/tokens.rs, src/api/websocket.rs)

Informational (3)

Raw internal errors returned to API callers (src/api/* all handlers)

/servers endpoint exposes host hardware and Docker internals to all authenticated callers (src/api/servers.rs)

container_id exposed in app responses (src/server/state.rs, src/api/apps.rs)

I have patches them all so it should be safe now. If you find more, please report them.

What’s next

The same as I said in last devlog. The panel itself.
I have made this devlog since I found a couple issues while testing and they were related to the security of the app.

Changelog

Attachment
0
Bram (QKing)

LaunchPad - Devlog #1

Hey! I’m building LaunchPad, a self-hosted panel + daemon combo for deploying and managing Docker containers. The goal is to be a simpler alternative to Pterodactyl Wings. Same idea though. Give it a server and it manages containers on it with ease.

What’s done so far:

The daemon is written in Rust. It talks to Docker directly and exposes a REST API backed by Postgres. Here’s what it can do right now:

Deploy app: pulls the image, creates the container, starts it, all in the background

Start / stop / restart / kill containers

Live logs and stats (CPU, RAM, network I/O)

Run commands inside a container + interactive shell over WebSocket

File browser: list, upload, delete files inside containers

Per-app Docker networking: isolated by default, connectable on demand

Webhooks: get notified when an app status changes

Per-app auth tokens: scoped so a user can only touch their own app

What’s next

The panel. The daemon has everything wired up. There are 25 endpoints covering most functions I need. Next step is building the frontend with user accounts so people can actually use it and I can start giving out containers for free for every HackClub member who needs it

Changelog

Attachment
0