HN Explorer

Show HN: Daytona – Open-source dev env manager from a 15-year journey (github.com)

73 points by ivan_burazin ↗ HN
Hey HN,

I'm Ivan Burazin, and for the past 15 years, I have been on a mission to streamline software development environments. Today, I'm excited to share the culmination of that journey: Daytona, an open-source Development Environment Manager designed to finally solve the issue of setting up dev environments, whether local or remote.

My journey in cloud development began in 2009 when my cofounder and I we launched the first (or at least one of) commercial Cloud IDEs, Codeanywhere. We developed everything in-house: the IDE, the orchestrator, and more. We garnered interest from over 2.5 million developers, and although it makes sense now, then we were ahead of our time.

Fast forward to today and remote development is commonplace, but the complexity of setting up environments has grown by a magnitude.

This is where Daytona comes in.

- What is Daytona?

Daytona is an open source, single-binary Development Environment Manager that lets you set up your development environment anywhere – local, remote, cloud – with a single command: ‘daytona create.’ It's free, flexible, and ready to use.

- Why Daytona?

*Simplicity*: Set up your dev environment with a single command. The only thing you need to need it to point to a repo and a target and Daytona automagicly does the rest.

*Flexibility*: Works on any machine, with any infrastructure.

*Open Source*: Fully transparent and community-driven.

- Getting Started:

We've made it super easy to try Daytona:

1. Download the single binary. 2. Run it on your machine – no signups, no emails, just straight to business.

We're excited to see how Daytona can streamline your development workflow. Try it out, push its limits, and let us know your thoughts, questions, and feedback right here.

GitHub: *https://github.com/daytonaio/daytona\*

I'll be around to discuss and answer any questions you have. Looking forward to ur feedback regardless.

Ivan Burazin Founder, Daytona

P.S.: For those who love the backstory and the technical journey, I've poured it all into a thread you can read here:

https://x.com/ivanburazin/status/1765392906054197674?s=20

24 comments

[ 4.0 ms ] story [ 51.9 ms ] thread
tpuljak
Hi all, Tpuljak here, one of the developers working on Daytona. Feel free to ask any questions!
nkko
Joining the conversation, as we are really excited about finally going open source!
lukedaytona24
Support Engineer from the Daytona team and super excited for this next step in the life of Daytona!
kiselitza
Just to congratulate you on going open source. I have nothing but high hopes and expectations for you folks.
taubek
It is nice to see such a project going open-source! Good luck!
rogvodarge
Congratulations on the release! Interesting stuff. But what is the difference between this and other tools like nix? If you are open to feedback, I feel like it is missing some lower level explanations of what problem this solves, preferably with screencasts showcasing how this can be used to solve it. I know that dev env setup can be a pain, but many of us have customized ways of doing this with dotfiles, nix, ansible, etc, and from reading the documentation I am not convinced this will fix any problem for me. But I am quite interested in learning more about this.
ivan_burazin
Thank you! Daytona is an automation tool that soon will support configuration files such as devcontainer or nix, both on the to-do list.

Daytona automates the creation of the development environment on any hardware, whether local or remote. It connects it to a local instance of VS Code (or to a browser if preferred), creates a VPN tunnel to the development environment, and adds a reverse proxy so you can share it as well.

Furthermore, it is acknowledged that an architecture diagram is missing, which would significantly aid in providing a clearer explanation. Efforts will be made to address this as soon as possible.

20after4
Even just this little explanation would be helpful on the daytona README. It wasn't obvious to me what exactly you meant by "creation of the development environment" ... that can mean a lot of different things that are fairly specific to each project and each developer as well.
meibo
> Second, approximately 50% of developers work in remote dev environments

I'm curious to know the source for this, it strikes me as odd. I wouldn't have put it anywhere close to even 5%, and it's hard for me to imagine how you would get there... maybe by counting containerization for dev purposes?

ivan_burazin
Hey there, you can find this data in the JetBrains report here: https://www.jetbrains.com/lp/devecosystem-2023/remote-dev/

There are also other sources, and the numbers might vary, but it is quite a significant number in all reports.

Note: 'remote' does not mean 'cloud'; rather, it indicates that the development environments are not on localhost

OJFord
'do you ever edit code on a remote machine' (which then further gets into Do you do that by SSH, Remote Desktop, or other) is pretty different than 'work in remote dev environments' implies.
mdaniel
You didn't ask me, but it seems unnecessary to sudo so many times in your curl|bash setup, doubly so when the user could be prompted for their sudo password without one shred of context what is being sudo-ed

    sudo curl $DOWNLOAD_URL -Lo daytona
    sudo mv daytona /usr/local/bin/daytona
    sudo chmod +x /usr/local/bin/daytona
could easily be

    curl -fsSLo daytona "$DOWNLOAD_URL"
    chmod +x daytona
    if [ -d        $HOME/.local/bin ]; then
        mv daytona $HOME/.local/bin
    elif [ $EUID == 0 ] && [ -d /usr/local/bin ]; then
        mv daytona              /usr/local/bin/
    elif [ $EUID == 0 ] && [ -d /opt/bin ]; then
        mv daytona /opt/bin/
    else
        echo 'Using sudo to relocate the binary to "/usr/local/bin"' >&2
        sudo mv daytona /usr/local/bin/daytona
    fi
and especially "curl -f for life" because there are few things more fun than chmod +x-ing an HTTP 404 response page

Since we're talking about things no one asked, it would further inspire confidence -- and also help your CDN costs! -- if they fetched from your releases page <https://github.com/daytonaio/daytona/releases>; to the best of my knowledge GH offers a "latest" URL so one need not hard-code version numbers in the shell script and at the same time says "this binary was produced from this tag" which the current shell script for sure does not. It turns out $(./daytona version) does cough up the version number but it would be more obvious if it were fetched from a release/tag URL

Thank you for attending my talk :)

metcalfc
:wave: Hi. Thanks for taking a look. Yeah, lots of things to improve. What gets me about this script is the the if/else would read better as a case statement. Chalk it up to a small team spending a lot of time re-architecting part of a commercial product out so we could open source it. We wanted to develop in the open and that meant shipping something.

Patches welcome. I'm going to be taking a pass at this script and a powershell script tomorrow. We also want to eventually get past curl and into brew/winget but we wanted to balance that with getting something out the door.

If you like packaging and scripts and want to help out we've got https://github.com/daytonaio/daytona/issues/102 tracking this at the top level.

jerrygenser
Very cool project. I'm looking forward to trying it. One note that's hindering me now is that it's very difficult to read the documentation, e.g. on this page: https://www.daytona.io/docs/installation/single-node/

There is very light gray font against a white background.

ivan_burazin
Thanks we need to edit the light theme, but also the docs as a whole as they are currently created for the enterprise product.

For now all the info you need is on the readme, but working on docs as we speak.

bitwize
Doot doo doot doo doot doo doot doo doo doooooooooooooooooo!

https://www.youtube.com/watch?v=YVlcADaT94o

The sudo-curl-pipe-bash pipeline makes me raise an eyebrow, but otherwise this looks like a step up in ease from faffing about with DevPod. Then again I'm a command line guy all the way, and DevPod is more GUI centric which may play well with other hackers' sensibilities (but it has a hidden CLI of its own).

ivan_burazin
As you might imagine, I spent numerous days in the arcade as a kid playing 'Daytona USA' :)

Regarding the pipeline, got it. I'm working on this and am glad you like the CLI-centricity of it.

bitwize
Have you tested various ssh client and terminal combos logging in to Daytona's devcontainers? I noticed that when logging in to DevPod's devcontainers, full-screen apps are glitchy, with one exception: Visual Studio Code's built-in terminal works fine.
metcalfc
I've tried many of the Mac terminals (iterm, kitty, ghostty) and Windows Terminal. openssh, mosh, tmux, and neovim all seem fine.
ivan_burazin
Yeah do let us know if you find any issues
bitwize
So I've been playing with Daytona using a version checked out and compiled with the Go toolchain.

I am experiencing the same ssh glitchiness that I did with DevPod. Full-screen applications such as Emacs and vim seem to newline randomly. I think this has to do with the fact that whatever Go ssh library is being used changes lf to crlf, if I recall correctly from my attempts to look into things with DevPod. So the ssh functionality is really only useful for running command line tools. The advertised VPN functionality appears to be missing.

The good news is that, unlike DevPod, whatever you're using for an ssh proxy plays nice with Emacs TRAMP mode. Overall, the UX is better than DevPod. I wish I had X11 forwarding or even a non-glitchy terminal, but it seems that the devcontainer ecosystem is set up to only really support Visual Studio Code.