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

• Updated database guide
• readme
• comment
• Delete panel/README.md
• README creation and update for final release
• Added a demo. WIP
• More templates
• Made dynamic templates supported
• Optimisation

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

• Fixed several vulnerabilities
• Made better comments

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

• Added gitignore for the builds to prevent uploading them by accident
• Initial commit

I have build and optimised a TUI for browsing FlavorTown projects. it is optimised in runtime, API requests and memory usage. Rust made it easier to do that since Rust is very efficient.

Added a fully fletched desktop and fix some bugs. This is the last devlog before the ship.
In the images below you can see what I have build!

Added memory management, extended my libc and started working on a filesystem. Also I was able to add mouse support so started working on the preparations for the simple desktop.

Added full gpu support + my own little libc I can use

Added:
Framebuffer support
GPU detection (nothing more, I can just detect them)
Power options (eg poweroff and reboot)
Snake game
Audio support
Music player with songs + piano
info command to show gpu info
polling for keyboards + better timer to run snake smoothly

Added a shell and the things that came alongside it. The ui is still the same, but instead of launching the demo program it launches my partially working shell. Keyboard support is smooth.

First day for Lock-In! Presenting an OS (from scratch) I have no name for yet! It’s 64 bit!
It’s written in C and uses Limine as a bootloader.

Features (What I made before this first devlog):

• Boots up and shows a simple screen with OS
• Displays the current time and timezone (Hardcoded UTC+0 currently)
• Can run small userspace programs
• Includes a test program called drawing
• Uses the real-time clock for proper delays and time

Made the core of the expansion and read docs…. A lot of reading…. The nexomaker docs weren’t that good at the time that I made this.
I was able to implement the file analysis and started working on build in console viewer.
Also I added the api method scan page.

I was succesfully be able to write a bootloader and a simple shell. The shell is based on a old C program I found laying around on my usb-stick. Currently there are no commands. I’m impresses that I got so far.

Last commits before the shipping.
I have fixed the bug that it trained on CPU only
I have fixed some parameters.
Added export and bundle functions to be able to use multiple networks as one!

I optimised the model. I have also improved the training and testing process to achieve way more accurate results. I have created the github repository and I pushed the changes.

I have made the basics of the prediction network. It’s light and predicts relatively good on my current dataset. I will integrate more dynamic features later and I will improve accuracy on different datasets.

I’m working on my first project! This is so exciting. I can’t wait to share more updates as I build.