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
Just to congratulate you on going open source. I have nothing but high hopes and expectations for you folks.
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
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
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 :)
> 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?
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).
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.
Support Engineer from the Daytona team and super excited for this next step in the life of Daytona!
Hi all, Tpuljak here, one of the developers working on Daytona. Feel free to ask any questions!
It is nice to see such a project going open-source! Good luck!
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.