The Readme is not consistent with Daytona standards. Additionally, all essential information regarding how to contribute and the structure of the documents has been deleted.

When you open https://github.com/daytonaio/docs in Daytona Ent/Codespaces you are welcomed with the screen below and can activate a preview with one command:

When you do the same with Docs not oly does it not work, it creates an error in Codespaces

We need clear step by step instructions in case where user needs to revert back to some previous version.

Take into consideration:

• remote server
• use of profiles
• use of targets

Feel that "Server" should be under Usage not reference?

Would leave reference for CLI, API and similar

Describe the bug
Some links are broken at daytona.io documentation page

To Reproduce
Steps to reproduce the behavior:

1. Go to 'https://www.daytona.io/docs/installation/installation/'
2. 1st broken link: add a git provider on front page.
3. 2nd broken link: use the cli on front page.
4. 3rd broken link builders
5. Click on it '
6. See error page.

Expected behavior

1. correct first link: Go to cli refer here.
2. correct second link: add a git provider refer here.
3. correct second link: builders refer here.

Screenshots

Desktop (please complete the following information):

• Any
• Daytona Version: Documentation [v0.21]

Additional context
Will add more broken links as soon as possible.

The brew install path was updated to daytonaio/tap/daytona. We should update that in the installation guide

Requested in #1. Detail how Daytona sets up port forwarding and any considerations users should make.

We should consider adding a full first onboarding flow inside docs, including instructions for external tools, for example VS code add code to shell, docker install, and all other papercuts.

@idagelic can we get? brew install daytona so @osslate can update this everywhere?

To help users understand how Daytona works, we need a clear architecture diagram. For simplicity, we'll draft (and potentially implement) the architecture diagram using Mermaid, so it's easily editable as Daytona evolves.

To facilitate patch versions of the docs (independent from Daytona itself), we should strip the patch version displayed on the website and leave it as x.y. After a discussion with @vedranjukic, it appears the patch element of Daytona releases are going to signify bug fixes.

Since Daytona patch versions don't introduce new features or change existing functionality, we can leverage the patch version to signify in-between docs updates and have the website display 0.16, 0.17, etc. rather than 0.16.0, 0.17.1 etc.

Current design missing a lot of elements see demo and our live docs side by side

Need designer to create in Figma following design standard of Daytona docs.

command for posix compatible shell:

daytona purge
sudo rm $(where daytona)

does not work in Ubuntu 20.04. Command where does not exist

Since it's possible to install Daytona through Homebrew, we should cover this in the 3rd party package management section of the guide.

If purge doesn't work, add manual instructions :

rm -rf ~/Library/Application\ Support/daytona

I suggest ensuring that the following command can be used in both Codespaces and Daytona: yarn run dev --host.

If it is compatible, consider editing the development container configuration to include this command. Here's how you can do it:

Check Compatibility in Codespaces:

Open your Codespaces environment.
Run the command yarn run dev --host in the terminal.
Verify if the command executes successfully.
Check Compatibility in Daytona:

Open your Daytona environment.
Run the command yarn run dev --host in the terminal.
Verify if the command executes successfully.
Edit Development Container Configuration:

If the command works in both environments, update the development container configuration (devcontainer.json)

As discussed in #1, this page will detail Providers (e.g. Docker, and in the future others like DigitalOcean, AWS, etc.) and Targets, explaining the distinction between both and how to configure them.

Syntax highlighting theme incorrect - Light mode
Current:

Figma:

@mikimih Please correct and double check rest of website.

Thanks

Post

daytona purge
sudo rm $(where daytona)

Missing stop service command missing

Context

• daytonaio/daytona#689

None of the spacings seem to be consist and very few are correct.

Please refer to Figma for correct spacing

Also make sure to correct this on dotfiles, Documentation, Contact, Changelog, Definitions...
@mikimih

Context

• daytonaio/daytona#600
• #18 (comment)

To encourage others to contribute to the docs, we should include a link to the source on GitHub for each documentation page. From there, people can choose to fork this repo and edit the file in a branch using GitHub's web editor, or at the very least, they will know where they can find the content of the doc on their filesystem.

This should be dynamically done with Astro, avoiding a scenario where we need to define the URL manually for each page.

The first table on a page appears to gain the correct styling, but subsequent tables are not styled correctly and appear out of place. See the CLI reference as an example (source code here). I can verify this also happens if I create another page with more than one table.

Tasks:

• Verify the table design matches Figma
• Investigate why the style isn't being applied to tables after the first one and implement a fix

We need an icon for the "Server" sidebar item.

cc: @mikimih @filipvecek

Clicking Daytona Server under Dive Deeper on homepage ends in 404.

This was either meant to be a separate page or the card/link should be changed to API reference and /reference/api

https://www.daytona.io/docs/reference/server

We should generate API docs pages from https://github.com/daytonaio/daytona/blob/main/pkg/api/docs/swagger.json.

Ideally, we find a tool that can generate astro pages at deploy time and serve them from the docs.

cc: @mikimih @filipvecek

Need an docs on how to completely remove Daytona from a machine.

Non-exhaustive list:

• CONTRIBUTING.md
• SECURITY.md

It needs to be added in path docs/ from the landing page.
In docs, prev/next works.

As per Figma, All text on light mode should be the same (note titles are a different shade)

Currently we have multiple and is barley readable

@mikimih

Reported by @Tpuljak. While we have a Version.astro component, there are some areas we need to change (such as the installation guide). Because we can't embed variables inside Markdown codeblocks out of the box, we need to explore other options.

We're not checking for broken links in open PRs. We should add a GitHub Action to check links and anchors.

There are two tasks to be completed here:

• A suitable drop-down design for a version selector. Users should be able to select the version of the docs they're viewing easily. Pinging @ivan-burazin for more input on the design front.
• Implementation of the necessary Astro components and infrastructure to deploy versioned docs to daytona.io

We should change npm references to yarn in the README since we prefer yarn and have yarn.lock already committed.

This component needs to be implemented for use across the docs:

Ideally the usage looks something like this:

<TabbedContent>
  <Tab title="From Daytona Dashboard">
    Markdown content _here_
  </Tab>
  <Tab title="Via Dashboard URL">
    Markdown content _here_
  </Tab>
</TabbedContent>

Would also be nice to have an optional icon attribute to set an icon appearing on the left of the tab title, but deferring to @ivan-burazin

cc: @mikimih

Context:

• daytonaio/daytona#531
• daytonaio/daytona#363

The Server reference doesn't describe the different key/values that can be configured by the user. This information needs to be added.

I really like how Fly structured their CLI installation page: Fly CLI Installation.

The content bar clearly shows what a user is looking for, whether it’s Win/Mac/Linux, and is organized with user needs in mind. Additionally, package managers are listed under the OS they fit.

Originally requested in #1.

Following on from #32 and #36, replace all the fenced admonitions with the new <Aside> component.

For consistency, the README should take style cues from the main Daytona project repo.

Currently, the CLI reference is edited manually for each release. It appears possible using Cobra (the CLI framework Daytona uses) to automate Markdown generation based on the commands/subcommands/flags it knows of at runtime.

Implementing this will allow us to generate precise, accurate CLI reference documentation for each release, and ensure that the docs reflect the exact state of Daytona. Once implemented, it means we will not need to manually edit or change the CLI reference docs for accuracy.

cc: @Tpuljak for implementation ideas

Issue to track the design of an Installation icon for the sidebar.

Context

• #25 (comment)
• Icon exists but needs some changes before merging.

cc: @mikimih @filipvecek - feel free to open a PR

It should cover the most common phrases used in the Daytona documentation as a helpful reference to refer to.