You are browsing as a guest. Sign up (or log in) to start making projects!

Clark Lab - self hosted PaaS

  • 3 Devlogs
  • 33 Total hours

A platform that lets you deploy and manage apps and databases on your own servers without needed DevOps knowledge.

Ship #2

This ship was focused on making ClarkLab more stable, easier to set up, and easier to fix when something breaks.

I improved the update flow by adding health-check based handling, so it can test a new version before switching over instead of jsut grabbing raw code. I also improved agent updates with release binaries, prebuilt binaries, version handling, and update patches.

Setup was another big focus. I added an API and Cloudflare setup wizard to help with env setup, prod config, tunnels, frontend vars, and install scripts. It is still early, but it is a step toward making it much easier to self-host clarklab.

I also improved node setup and reconnect behaviour. Online nodes can now be reconnected, unfinished node setups can be cancelled, and I fixed smaller issues around install commands, port notices, API banners, and frontend reconnect logic.

Health checks were added for services, with frontend status shown in the service detail page. Agent logs now use the journal too, making debugging easier if something breaks.

There were also security and general chore fixes, including agent auth patches, sysadmin-only node modification, stronger password reset handling, safer frontend logs, GitHub parsing fixes, and better CI/workflow checks.

Overall, this ship was not about new features (even tho i added some small ones). It was about making my project easier to update and easier to deploy.

  • 2 devlogs
  • 9h
  • 13.95x multiplier
  • 131 Stardust
Try project → See source code →
Open comments for this post

6h 1m 19s logged

I’ve been focused on making ClarkLab easier to set up, safer to update, and less annoying to fix when something breaks.

The biggest part of this was improving the update flow. After adding health checks, I worked on making updates more reliable by testing candidate containers before replacing the live API. This means ClarkLab can now check that the new version is actually healthy before switching over, instead of restarting and hoping it works. It should make updates more stble, especially when running it on your own server.

I also spent time improving agent updates. Agents can now be updated using release binaries, and I added more work around prebuilt agent binaries, release patches, and version handling. This should make agent updates cleaner and less dependent on building everything manually on the target machine.

Another big focus was setup. I added an api and Cloudflare setup wizard to make self-hosting easier. The goal is to guide people through the annoying parts like env setup, production configuration, Cloudflare tunnel setup, frontend variables, and install scripts. It is nowhere near perfect and used agentic assistance, but it is a big step toward making it easier to deploy without needing to manually configure every little option across multiple files.

I also improved the node setup flow. There is now a cancel setup button, so if you start setting up a node and mess something up, you are not just stuck with a half-created node. I also patched several small bugs such as the node install command.

For debugging, I updated agent logs to use the journal. This should make logs more useful and easier to understand when something goes wrong on a server. I thought this was important as i want this project to be usable for real infra. This feature is very much so in an early stage as i am nowhere near finished with it.

There were also a bunch of security and maintenance fixes. I patched agent authentication, blocked node modification for users who are not sysadmins, strengthened password reset handling, reduced the chance of sensitive data being exposed through frontend logs, and tightened GitHub repo parsing. I also updated workflow permissions and CI checks so changes are safer.

This devlog is again, not about new frontend features. It is mostly about making this project more stable, easier to deploy, and safer. The main thing I learned from the last ship is that setup still needs to be much easier, so I started moving toward a proper guided setup flow. I very much so want to keep improving that until someone can deploy ClarkLab without having to understand how it works completely first.

0
0
2
Open comments for this post

3h 21m 19s logged

I’ve been focused on making ClarkLab easier to use and more fixable if it breaks.

One part of this was improving how the app behaves when connections are unstable. I worked on frontend reconnect behaviour and node reconnection so online nodes can be reconnected at any time instead of requiring it to be not responding first. I also fixed issues around agent/API update handling, as there were issues when using the update tool.

I introduced health checks in this log as well. Services can now be configured for health monitoring, and the frontend displays health status in the service detail page so it’s easier to see what’s working and what needs attention without investigation.

Chore wise, I updated CI checks so changes are safer and easier to maintain.

On the UI side, I made a number of usability improvements when deploying it for youself: site URL editing on the frontend, cleanup toward a more minimal interface, masking node IPs behind a reveal action for privacy, and fixes for issues like the API banner behaviour, node install flow, and port allocation notices.

Based on feedback from the last ship, It’s clear that I need to make it easier to setup. I’m planning on making a CLI-based setup flow with env setup etc there, but, that is not built yet. Overall, this devlog is less about new frontend features and more about making ClarkLab feel more stable and less buggy.

0
0
3
Ship #1

I made the basis of Clark Lab, my in-house version of Coolify as an alternative to Vercel & Heroku, making it easy to deploy your own databases and apps from home. For security reasons the public demo is a youtube video showing off all of the projects features, you can very quickly and easily deploy the project for development via the read me in as little as two commands.

  • 1 devlog
  • 24h
  • 6.79x multiplier
  • 68 Stardust
Try project → See source code →
Open comments for this post

23h 31m 50s logged

In the last few weeks i have created an in-house and open-source version of coolify. I did this as i wanted a way to run coolify that i found easier and that i preferred UI wise. I am still making it so there is almost certainly issues relating to security but it is currently functional.

0
0
8

Delete project?

Are you sure you want to permanently delete this project? This action cannot be undone.

All devlogs, followers, and associated data will be removed.

Followers

Loading…