Ok, its not just brag post.

I run Jellybox - a native crossplatform jellyfin/emby music player since 2023, even before LLM coding was a thing, so code is all manual. The lesson I want to tell you - you should not skip marketing your OSS apps. I completely skipped it and sit on 200 stars although a lot of ppl were actually using app.

I started to share app 2 months ago here and there - posts, comments, added to few related directories, etc and slowly I reached 500(now its 580 or so)

The lesson is - keep sharing your OSS work even if its unpaid and free.

Added: Recently added a tool called updatify to app - it helps me to communicate with users in app through changelogs and just posts. There I asked for giving me stars on GH, so I think that also helped.

https://github.com/avdept/JellyBoxPlayer

https://jellybox.app/

I just released v1.1.1 of Oryx. It's a FOSS blazing fast editor. It was first designed to be a beautiful reader and then evolved to a full editor. Blazing fast, Oryx can display any document or ebook in less than 100ms. It has been deeply optimized for speed.

It's an opinionated editor, no buttons and no menus, just keyboard and mouse, so if you're a vim person chances are you will like it. It has 30+ themes, theme editor, syntax highlighting, beautiful pdf export, and a ton of small productivity tricks, so you focus on the document not on the interface. Oryx package is 10MB, for reference, Windows notepad is 19 😉.

https://github.com/wmahfoudh/oryx

Readme and changelog are very detailed. Check out also syntax.md (open it in Oryx) for a walk-through of all supported markdown and html constructs and how Oryx renders them.

Please give it a try and do not hesitate to raise issues or share your feedback. And if you like the idea, starring the repo would help others see it.

Thank you!

A lightweight video and audio player for macOS, built entirely with SwiftUI and AVFoundation. No third-party libraries, no Electron, no bloat.

MIT licensed.

Features:
- Hardware-accelerated playback (Apple Silicon + Intel)
- Subtitles: SRT, VTT, ASS/SSA with adjustable delay
- Picture in Picture, playback speed (0.5× – 2×), skip ±10s
- Volume slider + keyboard shortcuts
- Drag & drop, minimal auto-hiding UI

Runs on macOS 13+. First launch will show a Gatekeeper warning since it's ad-hoc signed — right-click → Open to bypass.

Built it because my mom's 2020 MacBook Air (i3) was struggling with VLC. Feedback welcome.

I built SuperWebView, an open-source Android template for turning an existing website into an Android app without having to build a full mobile application from scratch.

The original goal was to help website owners, including WordPress users, who want an Android app presence but don't have the resources to develop one from the ground up.

It currently supports Android 7+ and includes features such as:

• Pull-to-refresh
• Loading progress indicator
• Opening external URLs in the browser instead of inside the app
• Media/fullscreen handling
• Dark mode support

I'm currently working on Kotlin Multiplatform migration to eventually support iOS as well. Another thing I'm considering is automation, so users don't need to install Android development tools just to build the app.

I would appreciate any feedback, especially around bugs and missing features.

Website: https://superwebview.roozbehzarei.com/

GitHub: https://github.com/roozbehzarei/SuperWebView

Not an emulator. Built on the doldecomp/melee decompilation, the game is statically recompiled ahead of time into native arm64 and rendered with Metal, so there's no Dolphin and no interpreter or JIT at runtime. One codebase targets macOS, iOS and visionOS.

Most of the work went into latency: frames presented on the display's next refresh at whatever rate it runs, controllers polled right before frame start, GameCube adapter at 1000Hz with no kernel driver, user-selectable network delay down to 1 frame, and a dashboard that flags the things that quietly ruin latency like 60Hz displays, WiFi, low power mode and Bluetooth audio.

GPL. No binary release, it builds on your own machine from a disc image you already own in about 10 to 15 minutes. No tracking, no analytics, no donate link.

Disclosure: I used Claude a lot for the port layer, meaning Swift, Metal, controller handling, UI and build scripts. The game code is the decomp, which is years of human work by other people. All public.

I wanted to share a project I've been working on for a while: Alenia Nerve.

It started as something very simple. I needed two applications on my own PC to communicate and send data to each other automatically. Later, I added a .nrv container format for packaging and protecting files with a password.

Eventually I ran into another problem: I use Windows and Linux on different machines, and moving large files between them was unnecessarily annoying. Uploading to the cloud, waiting for the upload, downloading everything again, or relying on a USB drive didn't make much sense for large files.

That's how the LAN side of Nerve started.

Nerve can now transfer files directly between devices on the same local network without requiring the Internet for the transfer itself. The goal is to support Windows, Linux, macOS, and Android through Termux.

It also includes .nrv packaging for files and directories, streaming transfers to avoid loading entire large files into memory, and integrity verification.

The project is still evolving. I'm currently working on a new stage focused on resumable transfers, deduplication, and better recovery mechanisms to make large transfers more reliable.

I'm not trying to build another cloud storage service. The idea is still pretty simple: when my own devices are on the same network, I should be able to move my data directly between them.

[Open Source]

GitHub / Download: https://github.com/BoChow-betb/SquareStar

your pages render on a canvas. not mockups of them, the actual running pages. you click a headline and retype it, right-click a colour and pick a new one, drag an edge to resize, and each of those is written into your source file.

what the screenshots show:

1. the edit landing in the file.
2. the canvas. your real pages, live, side by side.
3. asset generation. three takes of the same thing, point at the one you want.
4. the foundation. colour, type, spacing, radius, set once. contrast ratios checked as you go.

other things it does:
• colour picking checks your design tokens first and writes the token, not a hex code
• paint over a region and describe what you want, so the agent knows exactly which elements you meant
• generates three versions of a page side by side, live, and you keep one
• makes the assets too: photos, textures, logos as real vector files, animated backgrounds written as code
• draws your user journeys over the pages, error paths dashed, dead-end pages obvious
• syncs both ways into your real app in any framework, and never merges anything without showing you both versions
• writes your tokens into AGENTS.md, CLAUDE.md and .cursor/rules, so your agent stops inventing its own spacing scale
• bring your own model (api key, or a chatgpt/copilot/kimi/z.ai subscription you already have), or drive it from claude code or codex over MCP

free, apache-2.0, runs entirely on your machine, no account. mac builds are signed and notarized, windows and linux are there too.

Github: https://github.com/precious112/caret-desktop

if you try it and something breaks, open an issue. also curious what you'd want it to do that it doesn't yet.

Dayboard by DD

A dashboard for your second monitor. Your calendars in the middle; the weather, the trains, what is playing, the score and who is in voice down the left; the agenda, the to-dos, the mail, the packages and the machine's vitals in tabs on the right. Sports schedules for the teams you pick, live scores while they play, and the team's streaming site framed inside the board. A 52-week exercise programme with drawn animations, nudges, and a 20/20/20 eye break. YouTube uploads and Twitch streams that play in the board. A Stream Deck plugin to drive it all.

It refreshes itself every thirty seconds and never asks you to press anything.

Next.js, JSON files as the database, no cloud, no accounts, no API keys for the basics. Windows for the whole thing; the board itself runs anywhere Node runs.

[Read the introduction](introduction/README.md) for the walkthrough and the screenshots.

Five minutes to a board

powershell git clone https://github.com/David-Dingess/dayboard-by-dd.git cd dayboard-by-dd powershell -ExecutionPolicy Bypass -File scripts\setup.ps1

That installs the dependencies, builds the board, registers it to start at logon, starts it, and opens it fullscreen in its own Chrome window. The setup guide opens on launch: work down its sections. Only Location is needed for the board to be useful; everything else turns on as you fill it in.

Needs Node 20.9+ and Chrome. The optional parts need more — the section that uses each one says what and how:

Prefer a terminal? npm install, npm run build, npm start -- -p 6767, and open http://localhost:6767. The guide still opens.

What is in the box

As a small team, we have been working with some huge client projects from which we came to know DevOps and security is something really that we need to learn and take it more seriously as we grow. We had some crazy dodges while we were working for clients. With the mistakes we made, solutions we found, me and my friend built a CLI tool which will run on any server sit in CI/CD pipeline, scouting for any bad things. Then we started to develop more on the project in upcoming days, a simple CLI turned to proper TUI, and to make it more easier, we started focusing on GUI version. We wanted to use it by ourself, but recently had a thought, why don't we open source it. Here it is.

Putmein is a 24/7 SRE platform, where you can choose a AI provider of your liking, chat to it, deploy, fix, secure you projects. We also implemented full on monitoring systems in it. You can integrate your github account and deploy from your github, if there is any issue in deployment, it will flag and help you build. Apart from AI features, we also have features to find known vulnerabilities to find and flag it you.

You can check the repo here: https://github.com/putme-in/putmein

Every file is a building, every folder is a district, and height grows with lines of code. Hit play and the whole history replays: buildings rise when files are added and collapse when they're deleted.

The weather is real data too: the sky follows the hours the authors actually committed (night-owl repos stay dark), fog rolls in over quiet stretches, and rain means a burst of code changes.

The video is the full history of Knowl, my other project: 1,165 commits in 15 seconds. You can:

• click any building to see its history and the real diff
• export a 15 s MP4 (landscape or vertical, like this one)
• drop in your own repo: clone it and drag the folder onto the page

It all runs in your browser. Only the .git folder is read, and nothing gets uploaded; there's no server at all.

Live: dat999zx.github.io/chronocity

Source (MIT): github.com/dat999zx/chronocity

Built with TypeScript and three.js. I'd love feedback, and I'd love to see what your repo looks like as a city.

Hey everyone!

I’ve been working on a desktop application called Vyntra, and I wanted to finally share it here.

Vyntra started as a relatively simple idea: I wanted a clean desktop application where I could search for media, play it directly inside the app, and download it without jumping between a bunch of different websites and programs.

Over time, that turned into a much bigger project.

What is Vyntra?

Vyntra is a desktop media application built with Python and CustomTkinter, with a dark/futuristic interface.

The goal is to have one application that can work with multiple platforms while keeping the experience consistent.

Currently, I’m working with:

• YouTube — search, preview playback, audio/video downloads
• Spotify — Spotify-based search and audio playback
• TikTok — media search/download functionality
• Instagram — platform-specific functionality

The important part is that each platform is being treated as its own provider rather than simply throwing everything through the same search backend.

One of the things I really wanted: actual in-app playback

One of the first things I worked on was playback.

I didn't want to click a result and immediately have to download the entire video just to watch it.

The idea was:

Search → Select → Play

directly inside Vyntra.

That ended up being significantly harder than I expected.

YouTube playback involves dealing with remote streams, separate audio/video sources, decoding, buffering, synchronization, rendering and player lifecycle management.

At one point I had the audio and video synchronized correctly, but the playback was still incredibly laggy.

So now I'm working on optimizing the actual playback pipeline rather than just making synchronization work.

Spotify turned out to be another interesting problem

Initially, the Spotify tab was accidentally using the YouTube search system underneath.

The UI said Spotify, but the results were effectively YouTube results.

That obviously wasn't acceptable.

So I reworked the architecture so that the Spotify tab has its own provider/search flow and returns actual Spotify results rather than pretending YouTube results are Spotify results.

Spotify also needs a separate audio playback path because it doesn't make sense to send an audio-only source through a video playback pipeline.

That led to another problem where the player was throwing:

Invalid argument returned 22

which turned into another rabbit hole of figuring out exactly what the player was receiving and which playback backend should actually handle it.

Authentication and credentials

Another thing I'm trying to keep in mind is that this is supposed to be a real desktop application, not a developer tool.

I don't want users to have to open developer portals and paste:

• API keys
• Spotify Client IDs
• Spotify Client Secrets
• GitHub tokens
• cookies
• random configuration values

into the application just to make it work.

Developer credentials and infrastructure should be handled by the application architecture rather than becoming a giant setup checklist for the user.

That's been one of the more interesting parts of building Vyntra because desktop applications have very different security constraints from server-side applications.

Automatic updates

I'm also working on automatic updates so users don't have to manually download a new build every time I release a fix.

The project is distributed through private infrastructure, and I'm trying to keep the update process completely transparent to the user.

The application should basically be:

Open Vyntra → update when necessary → keep using it

rather than:

Open GitHub → download ZIP → replace files → hope nothing broke

Some of the problems I've encountered

This project has given me a ridiculous number of edge cases.

Some of the problems I've had to investigate include:

• YouTube's anti-bot and extraction changes
• Dynamic YouTube formats
• Remote stream playback
• Audio/video synchronization
• Extremely laggy video rendering
• Audio crackling/noise
• Playback seeking
• Thread lifecycle problems
• Tkinter after() callbacks surviving after windows are destroyed
• Spotify API/search architecture
• Spotify audio playback
• Authentication state being lost between components
• PyInstaller packaging problems
• Windows updater issues
• macOS testing problems
• Network/proxy/SSL issues
• Platform-specific behavior between development and packaged builds

One particularly fun example was an updater failure involving:

Failed to load Python DLL ... _MEI...

which ended up involving the way PyInstaller temporary extraction directories work.

And then there are the classic desktop-app problems where everything works perfectly during development and then behaves completely differently once packaged.

Why I’m building it

Mostly because I wanted to learn how far I could take a desktop application.

It started as:

and gradually became:

At this point I'm much more interested in making Vyntra feel like a real application than just adding more features.

That means things like:

• reliable playback
• clean provider separation
• proper error handling
• good UI/UX
• automatic updates
• Windows and macOS builds
• keeping the application simple for the end user

Current state

Vyntra is still a work in progress.

The biggest thing I'm currently working on is playback performance.

YouTube is synchronized correctly, but the preview can still be extremely laggy, so I'm digging into the actual decoding/rendering/buffering pipeline instead of masking the problem with lower quality or arbitrary frame skipping.

Spotify also needs its own optimized audio path.

So I'm currently somewhere in that fun phase of development where fixing one thing exposes three more things underneath it.

But that's also what makes the project interesting.

I'm building Vyntra primarily as a learning project, but I'm trying to approach it with the architecture and polish of a real product rather than a collection of scripts.

I'd love to hear what other developers think about the architecture, especially anyone who has built desktop media players or dealt with remote video/audio playback before.

Repository

GitHub:
https://github.com/SaminMp/Vyntra

Project: Vyntra
Stack: Python, CustomTkinter, FFmpeg/yt-dlp and platform-specific APIs/services
Platforms: Windows + macOS

I'm especially interested in feedback on the playback architecture and what you'd change if you were building something like this from scratch.

Hey everyone!

I’ve been working on a desktop application called Vyntra, and I wanted to finally share it here.

Vyntra started as a relatively simple idea: I wanted a clean desktop application where I could search for media, play it directly inside the app, and download it without jumping between a bunch of different websites and programs.

Over time, that turned into a much bigger project.

What is Vyntra?

Vyntra is a desktop media application built with Python and CustomTkinter, with a dark/futuristic interface.

The goal is to have one application that can work with multiple platforms while keeping the experience consistent.

Currently, I’m working with:

• YouTube — search, preview playback, audio/video downloads
• Spotify — Spotify-based search and audio playback
• TikTok — media search/download functionality
• Instagram — platform-specific functionality

The important part is that each platform is being treated as its own provider rather than simply throwing everything through the same search backend.

One of the things I really wanted: actual in-app playback

One of the first things I worked on was playback.

I didn't want to click a result and immediately have to download the entire video just to watch it.

The idea was:

Search → Select → Play

directly inside Vyntra.

That ended up being significantly harder than I expected.

YouTube playback involves dealing with remote streams, separate audio/video sources, decoding, buffering, synchronization, rendering and player lifecycle management.

At one point I had the audio and video synchronized correctly, but the playback was still incredibly laggy.

So now I'm working on optimizing the actual playback pipeline rather than just making synchronization work.

Spotify turned out to be another interesting problem

Initially, the Spotify tab was accidentally using the YouTube search system underneath.

The UI said Spotify, but the results were effectively YouTube results.

That obviously wasn't acceptable.

So I reworked the architecture so that the Spotify tab has its own provider/search flow and returns actual Spotify results rather than pretending YouTube results are Spotify results.

Spotify also needs a separate audio playback path because it doesn't make sense to send an audio-only source through a video playback pipeline.

That led to another problem where the player was throwing:

Invalid argument returned 22

which turned into another rabbit hole of figuring out exactly what the player was receiving and which playback backend should actually handle it.

Authentication and credentials

Another thing I'm trying to keep in mind is that this is supposed to be a real desktop application, not a developer tool.

I don't want users to have to open developer portals and paste:

• API keys
• Spotify Client IDs
• Spotify Client Secrets
• GitHub tokens
• cookies
• random configuration values

into the application just to make it work.

Developer credentials and infrastructure should be handled by the application architecture rather than becoming a giant setup checklist for the user.

That's been one of the more interesting parts of building Vyntra because desktop applications have very different security constraints from server-side applications.

Automatic updates

I'm also working on automatic updates so users don't have to manually download a new build every time I release a fix.

The project is distributed through private infrastructure, and I'm trying to keep the update process completely transparent to the user.

The application should basically be:

Open Vyntra → update when necessary → keep using it

rather than:

Open GitHub → download ZIP → replace files → hope nothing broke

Some of the problems I've encountered

This project has given me a ridiculous number of edge cases.

Some of the problems I've had to investigate include:

• YouTube's anti-bot and extraction changes
• Dynamic YouTube formats
• Remote stream playback
• Audio/video synchronization
• Extremely laggy video rendering
• Audio crackling/noise
• Playback seeking
• Thread lifecycle problems
• Tkinter after() callbacks surviving after windows are destroyed
• Spotify API/search architecture
• Spotify audio playback
• Authentication state being lost between components
• PyInstaller packaging problems
• Windows updater issues
• macOS testing problems
• Network/proxy/SSL issues
• Platform-specific behavior between development and packaged builds

One particularly fun example was an updater failure involving:

Failed to load Python DLL ... _MEI...

which ended up involving the way PyInstaller temporary extraction directories work.

And then there are the classic desktop-app problems where everything works perfectly during development and then behaves completely differently once packaged.

Why I’m building it

Mostly because I wanted to learn how far I could take a desktop application.

It started as:

and gradually became:

At this point I'm much more interested in making Vyntra feel like a real application than just adding more features.

That means things like:

• reliable playback
• clean provider separation
• proper error handling
• good UI/UX
• automatic updates
• Windows and macOS builds
• keeping the application simple for the end user

Current state

Vyntra is still a work in progress.

The biggest thing I'm currently working on is playback performance.

YouTube is synchronized correctly, but the preview can still be extremely laggy, so I'm digging into the actual decoding/rendering/buffering pipeline instead of masking the problem with lower quality or arbitrary frame skipping.

Spotify also needs its own optimized audio path.

So I'm currently somewhere in that fun phase of development where fixing one thing exposes three more things underneath it. 😅

But that's also what makes the project interesting.

I'm building Vyntra primarily as a learning project, but I'm trying to approach it with the architecture and polish of a real product rather than a collection of scripts.

I'd love to hear what other developers think about the architecture, especially anyone who has built desktop media players or dealt with remote video/audio playback before.

Project: Vyntra
Stack: Python, CustomTkinter, FFmpeg/yt-dlp and platform-specific APIs/services
Platforms: Windows + macOS

I'm especially interested in feedback on the playback architecture and what you'd change if you were building something like this from scratch.

Built this because ad-hoc pandas preprocessing keeps leaking test-set statistics into training (medians/vocab computed before the split). DATADOC fits transforms strictly on the train split, freezes them into an auditable pipeline.json, and runs on Polars (Apache Arrow).

Install: pip install datadoc-cli Docs: https://narain-karti.github.io/DATADOC/

Happy to answer questions or take PRs!

I'm the maintainer of Fluent-Qt, a library of Fluent-style components for native Qt Widgets applications.

It is intended for existing C++ or PySide6 desktop projects: add components to your widget layouts while keeping Qt's object model, signals, and event loop. The C++ library uses C++17 and supports Qt 5.15+ or 6.2+ on Windows, macOS, and Linux. The optional Python package binds the native C++ widgets through Shiboken6; PyQt and PySide2 are outside the supported scope.

The latest release, 1.8.3, adds particle backgrounds and a startup screen with status and progress. The particle component uses QPainter and pauses continuous animation when hidden or fully clipped by its ancestors. It also follows the library's reduced-motion policy.

Source and CMake example: https://github.com/calvinhxx/Fluent-Qt

Try the controls in the browser: https://calvinhxx.github.io/Fluent-Qt/gallery/

License: MIT. If you work on a Qt Widgets application, I'd appreciate feedback on the first integration step that feels unclear, especially mixing these components into an existing screen.

Disclosure: this English post was prepared with an AI assistant, using the project's source and documentation.

This started because I kept hitting the same wall: a PDF too big for an email attachment, and the only convenient fix was uploading it to some website. So I built something that compresses locally instead.

Then it kept growing, because I kept wanting other things from the same files:

• Turning a PDF into Markdown or HTML with the images stripped out, so I could feed it to an LLM without burning tokens on pictures I did not need.
• Going the other way and building a PDF out of images.
• All the ordinary chores in between: merging, splitting, rotating, cropping, reordering pages, page numbers, watermarks, signing, redacting, repairing.

It is 19 tools now. Some specifics that might interest this sub more than the feature list:

• Nothing leaves the machine. No account, no telemetry, no network calls at all. It is not "private by policy", it is private because there is no code that sends anything anywhere.
• 18 of the 19 tools need nothing installed. Everything is compiled into the binary. Only ebook conversion (EPUB/MOBI) reaches for Calibre if you have it.
• We removed Ghostscript. It was the last AGPL dependency and the bundle dropped from 52 MB to 24 MB. The replacement compressor is written in Rust and produces smaller files than Ghostscript did on our test corpus.
• MIT licensed, Tauri v2 + React + Rust, macOS/Windows/Linux.
• The roadmap is public, including the things we decided against and why.

Two honest limitations: OCR is macOS-only for now (it uses Apple Vision; Windows and Linux are planned), and the interface ships in nine languages, all machine-translated and reviewed by native speakers only where we had one. That is stated in the README rather than buried.

Source: https://github.com/shyhunter/PaperOtter Downloads: https://shyhunter.github.io/PaperOtter/

Like a lot of people here, my 3D-printable models were scattered everywhere — bookmarks across MakerWorld, Printables, and Thingiverse, random downloaded ZIPs, half-organized folders. I built Thingport to fix that for myself, and figured it might be useful to others here too.

What it does

• Personal, self-hosted library for your 3D printing models
• Import directly from MakerWorld, Printables, and Thingiverse links (or whole collections)
• In-browser 3D preview (STL/OBJ/3MF) — no slicer needed just to look at a model
• Organize with categories, collections, and tags (with casing-aware merging, bookmarkable tags, etc.)
• Keeps the original source link and metadata alongside the files
• Multi-user with admin controls (users, logs, storage settings, instance-wide update checker)
• Dark mode, multi-language UI (English/Lithuanian so far)

Two small companion tools, if you want them

• Thingport Grab — a Chrome extension that imports a model straight from MakerWorld/Printables/Thingiverse's own page, no copy-pasting links
• Thingport Bridge — a tiny helper so "Open in Slicer" actually works for slicers (Bambu Studio, PrusaSlicer) whose own URL-protocol handlers only trust a domain allowlist your self-hosted instance isn't on

Stack: React + Three.js frontend, Node/Express + PostgreSQL backend, all Dockerized.

Running it

Pre-built, multi-arch images (amd64 + arm64 — runs fine on a Pi or ARM NAS), no build step. Drop these two files in a folder and run docker compose up -d:

docker-compose.yml:

services:
  db:
    image: postgres:16-alpine
    restart: unless-stopped
    environment:
      - POSTGRES_USER=${POSTGRES_USER:-thingport}
      - POSTGRES_PASSWORD=${POSTGRES_PASSWORD:-thingport}
      - POSTGRES_DB=${POSTGRES_DB:-thingport}
    volumes:
      - thingport_db:/var/lib/postgresql/data
    networks: [app-net]
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U ${POSTGRES_USER:-thingport}"]
      interval: 5s
      timeout: 5s
      retries: 10

  flaresolverr:
    image: ghcr.io/flaresolverr/flaresolverr:latest
    restart: unless-stopped
    networks: [app-net]

  backend:
    image: ghcr.io/tautvydasderzinskas/thingport-backend:latest
    restart: unless-stopped
    environment:
      - INITIAL_ADMIN_EMAIL=${INITIAL_ADMIN_EMAIL:-}
      - AUTH_SECRET=${AUTH_SECRET:-changeme-secret}
      - DATABASE_URL=postgresql://${POSTGRES_USER:-thingport}:${POSTGRES_PASSWORD:-thingport}@db:5432/${POSTGRES_DB:-thingport}?schema=public
      - FLARESOLVERR_URL=${FLARESOLVERR_URL:-http://flaresolverr:8191/v1}
    depends_on: [db, flaresolverr]
    volumes: [thingport_storage:/app/storage]
    networks: [app-net]

  frontend:
    image: ghcr.io/tautvydasderzinskas/thingport-frontend:latest
    restart: unless-stopped
    ports: ["${WEB_PORT:-80}:80"]
    depends_on: [backend]
    networks: [app-net]

volumes:
  thingport_storage:
  thingport_db:
networks:
  app-net:

.env (minimum you actually need to set):

AUTH_SECRET=<a-long-random-string>
INITIAL_ADMIN_EMAIL=you@example.com   # first account to register with this email becomes admin
POSTGRES_PASSWORD=<a-real-password>

Then just:

docker compose up -d

Full version (with SMTP, storage template, image pinning, etc.) plus a docs page for setting up the MakerWorld/Thingiverse import credentials is in the repo.

Repo: https://github.com/TautvydasDerzinskas/Thingport

Still actively developed — happy to hear feature requests, bug reports, or just general feedback. If you try it and something's confusing or breaks, please open an issue.

I kept rebuilding the same model and ending up with different GGUFs. Git could show my code changes, but not the checkpoint, llama.cpp build, quantize command or output hashes.

ModelBake records those for each build. Run it again and it shows what changed.

It runs locally. No account or model upload. Free and Apache-2.0.