Document the use of env variable conventions. These are used to authenticate custom container registries.

For example

GITLAB__CONTAINER_REGISTRY_SERVER=some-project.gitlab.com
GITLAB_CONTAINER_REGISTRY_USER=some-username
GITLAB_CONTAINER_REGISTRY_PASSWORD=some-password

It works similar to Coder's Extenal Auth https://coder.com/docs/admin/external-auth

Workspace classes should be described in detail (why they exist and what parameters can be set).
The information should explain the maximum limits based on the hardware node availability in the cluster.
GPU availability should be highlighted.

Overprovisioning should be explained - how it works and the pros and cons of setting the overprovisioning factor.

https://www.gitpod.io/docs/configure/workspaces/workspace-classes

Description

In the documentation, certain CLI commands lack syntax highlighting.

This issue is occurring from the use of triple backticks ( ) instead of specifying the language for syntax highlighting (bash).

Making this minor adjustment will apply the appropriate syntax highlighting to the CLI commands, enhancing readability and clarity for users.

And I Want to Work on this

ScreenShot

Expected:

What we got:

Need to add admin section to docs as we now have admin dashboard with:

• licence
• workspace-classes
• users

Provide an explanation including requirements and/or limitations around Kubernetes.

Workspaces can be "pinned," which will exclude them from the cleanup procedure if they are unused.

The docs should explain why workspaces are automatically cleaned up, that the cleanup conditions are configurable, and how to use the Pin feature to prevent a workspace from being destroyed if it is unused.

On a fresh macOS install, the Daytona installer spits out this message while running as an unprivileged

Warning: Destination directory /usr/local/bin does not exist.
         Create the directory:
           mkdir -p /usr/local/bin

Running the installer as an unprivileged user, the suggested mkdir will fail.

Potential solutions:

1. Have the Daytona install script offer to execute the mkdir command using sudo instead of printing this message and immediately exiting.
2. Keep the same message, but add a check to the script to see if we're running as a privileged user. If not, prepend sudo in the suggested mkdir command.

Create information relating to the use of Machine Size and allocation (teams etc) AND GPU Support

Describe the bug
Environment Secret Value has a maximum of 50 characters only?
Cannot add many of my secret values, they are all longer.
Or is the intention that I have to use something like Doppler?

To Reproduce
Steps to reproduce the behavior:

1. Go to 'Dashboard: Env Variables"
2. Enter Secret Value
3. Only the first 50 characters are stored
4. That is too short to host my secrets here.

Expected behavior
Secret Value Fields to accept longer values.

Desktop (please complete the following information):

• OS: Ubuntu 24
• Daytona Version: current https://github.com/daytonaio/enterprise-demo/setup.sh
  Do not see any version tags anywhere.

Description

In the CLI docs, the Daytona Command is missing!

Steps to reproduce:

• Go to https://www.daytona.io/docs/tools/cli/#command--daytona
• Check the Daytona Command.

Screenshot:

Create / edit Getting Started page - perhaps using description of Daytona as per Vedran's video/Loom (First 5 minutes)

https://www.loom.com/share/5c73389fc8814ef5a38d1a0829bc6aad?sid=9b79e439-c876-48a9-80f4-45887896e096

The installer script doesn't check to see if the user has Docker installed as a prerequisite to using Daytona. Once Daytona is installed, it does spit this error message out when you try to create a workspace, but it could be made friendlier and caught earlier in the onboarding process:

FATA[0062] failed to create workspace: Cannot connect to the Docker daemon at unix:///var/run/docker.sock. Is the docker daemon running?

I reviewed the content in the Teams section of the documentation. I think we need to add the following things:

1. Add steps for inviting members via email

2. Add info for importing in bulk via CSV file (use the instructions available in the dashboard)

3. In the managing members section, more info should be added regarding the change role/transfer ownership action

4. We are missing a section which explains the differences between different team roles

Because Daytona performs a single-branch clone when creating projects, the user is unable to fetch all remote refs by default.

This might be confusing for users so we should add a docs entry that explains how to enable fetching all remote refs.

This guide is very helpful in achieving this.

Screenshots:

Daytona collects anonymous telemetry data to with the goal of improving the Daytona ecosystem.

The docs should explain what data is collected and the flow for opting-out.

The docs should have a dedicated section on how to configure and use the SSH Connection to a Workspace.

This should cover the Public key auth and the Access token auth.
The Access token auth should be explained, like when to use it and how it works.

The new flow needs to be documented, as now we have more options on the "Create Workspace" form than before: Git repo URL, IDE choice, and the Workspace Class selector.

The update must include links to describe the Workspace Classes and the section on available IDEs.

Readme should be edited to be consistent with Daytona and OSS Docs repo

Workspace templates (samples) show up as suggested repositories when creating a new workspace.

The docs should explain how these templates can be configured and linked in the Daytona admin dashboard.

On checkout the process to start the dev view should be identical to OSS docs

When the application runs in the workspace, Daytona will detect the port and will create a preview link that can be shared with other users.
The link can be set to private or public.

Daytona admins can manage which IDEs can be used for opening workspaces.

Docs run in Codespaces but not in Ent Daytona
ELIFECYCLE  Command failed with exit code 134.

The Reach support link in the footer is invalid.

I assume it should be an email link to [email protected].

Daytona supports three user roles: Admin, Team owner, and Team member (developer).

The documentation should describe what features are available to each of the roles.

Need to add minimum resource requirements for cloud installation.