Show HN: Lapdev, a new open-source remote dev environment management software (opens in new tab)

I spent more than a year living with the numerous downsides of high level CDE (containerized development environment) tools. I must admit that I am very skeptical about all options available right now and that I have rolled back to using plain, old school, docker compose based CDE.

Both .devcontainers and .devfile managed to create more effort than they took away. Some key points:

- long lived containers

- abstracting away the fact that you run stuff inside containers in the IDE and abstracting away the container life cycle

- cryptic error states and error messages, especially when setting up new projects from scratch. This often boiled down to bad plugins (even Microsoft's own VSCode plugins wet the bed often)

- only superficial support for podman

- bad support for arm based HW (and arch translation issues, like a tool requesting arm containers but the host running docker is x64)

At this point I consult teams to try out a plain compose.yml as a CDE and skip the "enterprise" stuff.

> JetBrains’s remote SSH dev;

Does that require a static ip on remote?

I have skimmed the Jetbrain FAQ [1] and it says "no relay servers are involved"

[1] https://www.jetbrains.com/help/idea/faq-about-remote-develop...

If this is what I think it is, Visual Studio Code has an extension that does this as well.

there are products that do this out of the box fairly well. code spaces is an example with a single node but there are others - all of which are slightly different

Sorry it’s not meant to be a dig at you, but in I wish we could stop talking about the “cloud” and software running “in the cloud”.

There is no cloud… it’s just software running on someone else’s computers that you don’t control. And that someone else is usually a megacorp like Microsoft or Amazon.

Founder of coder (https://github.com/coder/coder) here. We choose Terraform as our provisioning layer so that users can provision full blown VMs as their development environment.

We have many teams using GPUs with Coder for ML workloads but doing GUI/Game remote development where interactivity is essential remains elusive.

You can access GPUs within containers using CDI (Container Device Interface): https://docs.nvidia.com/datacenter/cloud-native/container-to... No additional tools (e.g., nvidia-ctk) are needed. Docker has recently added support for CDI in version 25.0.

Having deployed a few of these over the last month or so, I feel like the devcontainer spec is very annoying. The alternative is what Coder does -- write some arbitrary terraform to bring up or down a workspace. I think this is better because I tend to need other things to go in a workspace (like an IAM role to access dev databases, associated Kubernetes resources, etc). With terraform I can configure whatever infrastructure I want to go along with workspaces.

The main downside I can see is that users have to write their workspaces for a particular deployment target. This would be a problem for e.x. open source projects trying to check in a workspace definition file of some kind. We standardize on Kubernetes across clouds and bare metal so it's not an issue for us, but it makes sense that it would be an issue for other use cases.

Devcontainers bring notions such as configuring plugins for your IDE, getting « features » from other repos / registries, managing environment variables that you pass from host to devcontainer, and finally either code locally or in the context of a remote environment with more resources or just simply in the context of the rest of your application (very handy for complex network or security setups).

Just two weeks ago we have outsourced Daytona (daytonaio) under an Apache license. We had long and deep discussions but finally decided that's the only thing that made sense.

AGPL is Free Software according to the FSF, so I'm not sure who at all would contest that it isn't.

https://devenv.sh/ and nix in general are great for setting up dev environments.

Hi, Lapdev dev here. Let me try to answer your question.

It's installed on a remote server so it provides remote environments. If you use VSCode remote, then you can "open" it through VSCode remote ssh.

The environment that Lapdev provides essentially is a container (other format is on the roadmap) with things pre-installed as defined in Devcontainer(https://containers.dev/) format.

We've been focused on developing remote-first solutions for years (Codeanywhere). However, we ultimately concluded that, with Daytona, local will always be the primary environment, with remote serving to enhance specific needs like scaling and offloading is the right way to go. Therefore with Dayton you can spin your dev env on different targets and providers.

Well, developers seem to love writing "configuration" rather than "code" these days. But basically a container + the necessary tools IS a devcontainer. It's just a way of automating the "putting in the necessary tools" part especially if you need things that might need to be added to a base container, or services that need to be configured differently based on the external environment that you don't want to bake in for some reason.

If you've ever had to cut and paste a 50 line docker run command snippet but you forgot that one volume mount or port or ENV var that someone added a dependency on last week then you pretty quickly realize just doing complex docker things by hand is a pain. Another example, if you have a script that you want to run to fetch the latest authentication token from a vault after the container launches because you don't want to store it inside the container. Sure, you could write a bash script to run all these steps inside the container after you launch it but it's nice to have a config file to share with another dev and just say: use this.

And the secondary benefit is that having a config file for the editor (like VSCode) so that plugins can manage all of that stuff better. Generally a dev container runs the VSCode Server, and they know how to talk to each other which can make remote development easier. For example, now I can launch the same dev environment locally or on the 56 core xeon 1TB ram server at the office and it's exactly the same as far as the editor is concerned.

It looks like this project is an alternative to the VSCode Server. My team generally uses docker-compose for this since not everyone uses VSCode.

It makes it easy to point the tool at a Git repo, have it automagically create a containerized environment for that repo with all its dependencies, and open Visual Studio Code on the codebase inside that remote containerized environment.

Devcontainer was created by Microsoft to support Visual Studio Code's remote development features, so it works best in Visual Studio Code. Inasmuch as other IDEs support it, that's up to the IDE vendor.

One angle is to simplify the setup of what you described. You can do this manually with Docker already, but the DevContainers config means your editor will do it for you.

Another angle is rent-seeking and locking you into a proprietary, expensive ecosystem. Big Tech has successfully convinced most companies to overpay by orders of magnitude for compute and bandwidth, but so far local development machines were excluded. This aims to tackle that shortcoming and make sure you enjoy all the "benefits" of the cloud even during development.

JSON, everything has to either be YAML or JSON.

If I didn't invent the thing, then we shouldn't use the thing. Dockerfiles fall into this class too, they are just a shitty homegrown DSL.

I haven't yet tried lapdev but have read somewhere that they have included a web ide, just like ours daytona comes out of the box with open vs code web ide.

A few things Lapdev can probably do better:

Devcontainer spec is probably more developer centric than Proxmox templates

I would guess with your Proxmox setup in a team setup, you'd need to assign a hostname/ip for different developers, where with Lapdev you have a single point of access.

Lapdev can proxy http traffic to the workspace containers with authentication, which makes it easy to preview things with security.

Do you work for Promox? Because it looks like a very corporaty over engineered solution.

Lap dev looks like a much simpler tool

It isn't easy to open-source your baby. It wasn't easy for us when we went Apache, so I can relate. It is hard to build a truly open-source business model.

Yeah I wonder why they didn't go with Apache or MIT

Running a Postgres container from docker compose (or whatever method you want) is up there with easiest one-and-done 2 minute development setup tasks I can think of.