diff --git a/articles/20260901_How_Daytona_Works.md b/articles/20260901_How_Daytona_Works.md
new file mode 100644
index 00000000..82051a4d
--- /dev/null
+++ b/articles/20260901_How_Daytona_Works.md
@@ -0,0 +1,98 @@
+---
+title: 'How Daytona Works: Core Concepts Explained'
+description:
+  'A guide to Daytona's architecture, setup, and workflow — covering
+  environments, prebuilds, security, and how it compares to alternatives.'
+date: '2026-09-01'
+author: 'Shreya'
+tags: ['daytona', 'devops', 'developers', 'dev environments']
+---
+
+# How Daytona Works: Core Concepts Explained
+
+# Introduction
+
+There's a point in every developer's journey where "it works on my machine" stops being a joke and starts being a real problem. Setting up a new project, onboarding a teammate, or reproducing a bug across different machines can eat up hours that should be spent writing code. Environment inconsistency — different OS versions, mismatched dependencies, forgotten configuration steps — is one of the most common and avoidable sources of friction in software development.
+
+[Daytona](https://www.daytona.io) is an open-source, self-hosted platform built to solve exactly this problem. It gives every developer on a team the same reproducible [development environment](../definitions/20240819_definition_development%20environment.md), whether they're working on a laptop or a cloud server. In this article, we'll walk through how Daytona actually works under the hood — its core concepts, architecture, setup process, and how it compares to alternatives like GitHub Codespaces and Gitpod.
+
+## TL;DR
+
+- **What it is**: Daytona is an open-source, self-hosted platform that creates consistent, reproducible development environments for individuals and teams.
+- **Core idea**: It packages tools, dependencies, and configurations into a shared blueprint, so every developer gets the same setup regardless of their machine.
+- **Key features**: Fast environment creation via `daytona create`, [Prebuilds](../articles/20241212_Prebuilds_in_Daytona.md) for near-instant startup, and support for VS Code, JetBrains, Vim, and Web IDEs.
+- **Why it matters**: It eliminates "works on my machine" issues, speeds up onboarding, and keeps environments secure and consistent as teams scale.
+- **How it compares**: Unlike closed-source options like GitHub Codespaces, Daytona is fully open-source (Apache 2.0) and can be self-hosted or run in the cloud.## What is Daytona?
+
+Daytona is an open-source environment manager designed to streamline and secure the setup and management of [development environments](../definitions/20240819_definition_development%20environment.md). At its core, it takes the manual, error-prone process of configuring a dev environment — installing the right language versions, tools, and dependencies — and turns it into a single, repeatable command.
+
+**Key Point:** Daytona is licensed under Apache 2.0, meaning it's free to use, fork, and self-host, unlike closed-source competitors such as GitHub Codespaces.
+
+### Open-Source and Self-Hosted Advantages
+
+Because Daytona is open-source, teams aren't locked into a vendor's infrastructure or pricing model. You can run it on your own servers, giving you full control over data, security, and cost. This is especially valuable for organizations with strict compliance requirements or teams who simply want to avoid recurring cloud costs for something as fundamental as their dev environment.
+
+At the same time, Daytona isn't limited to self-hosting - it also supports a cloud-based option for teams that prefer a managed experience without maintaining their own infrastructure.
+
+## Daytona's Architecture
+
+Daytona's platform is organized into three main planes, each responsible for a distinct part of how sandboxes and environments are created and managed.
+
+- **Interface plane**: Provides the client interfaces developers use to interact with Daytona — the CLI, SDKs, and dashboard.
+- **Control plane**: Orchestrates all sandbox operations, handling requests like creating, starting, stopping, and deleting environments.
+- **Compute plane**: Runs and manages the actual sandbox instances — the isolated environments where code executes.
+
+### Components of a Daytona Setup
+
+A typical Daytona setup involves a few core building blocks working together:
+
+- **Sandboxes**: Fully composable computers with complete isolation — their own kernel, filesystem, network stack, and allocated CPU, RAM, and disk. Sandboxes are the core unit of execution in Daytona.
+- **Snapshots**: Stateful environment captures that let you persist and reuse a sandbox's exact state across sessions, which is especially useful for long-running agent workflows.
+- **Project Configuration**: Stores everything needed to define a project — repository URL, build configuration, and environment variables — so environments can be reproduced consistently.
+
+**Note:** Sandboxes are built on OCI/Docker compatibility, which is what allows them to spin up quickly (often in under 90ms) while still supporting massive parallelization.
+
+### How It Interacts with Cloud and Local Infrastructure
+
+Daytona can run entirely self-hosted on your own infrastructure, or as a managed cloud service. Either way, the same interface and control plane logic applies — the compute plane simply runs on whichever infrastructure you've configured, whether that's your own servers or Daytona's hosted regions.
+
+## Setting Up Daytona
+
+Getting started with Daytona is designed to take minutes, not hours. Here's the general setup flow:
+
+### Prerequisites
+
+- A GitHub, GitLab, or GitLab Self-Managed account, if you plan to connect a repository.
+- Docker installed locally, if you're self-hosting rather than using the cloud-based option.
+
+### Installation Process
+
+**Self-hosted:**
+
+```bash
+daytona server
+```
+
+This starts the Daytona server on your own infrastructure, giving you full control over where environments run.
+
+**Cloud-based:**
+
+1. Create an account at [app.daytona.io](https://app.daytona.io)
+2. Generate an [API key](https://app.daytona.io/dashboard/keys)
+3. Create a sandbox using the CLI, SDK, or API
+
+Example using the Python SDK:
+
+```python
+from daytona import Daytona, DaytonaConfig
+
+config = DaytonaConfig(api_key="YOUR_API_KEY")
+daytona = Daytona(config)
+sandbox = daytona.create()
+response = sandbox.process.code_run('print("Hello World!")')
+print(response.result)
+```
+
+### Basic Configuration and Initial Setup
+
+Once Daytona is running, the next step is typically setting up a [Project Configuration](https://www.daytona.io/docs/usage/projects/#project-configuration) — this stores your repository URL, build settings, and environment variables so future environments can be created consistently. This configuration becomes the foundation for features like [Prebuilds](../articles/20241212_Prebuilds_in_Daytona.md), which we'll cover shortly.
\ No newline at end of file
diff --git a/authors/shreya_singh.md b/authors/shreya_singh.md
new file mode 100644
index 00000000..71c99885
--- /dev/null
+++ b/authors/shreya_singh.md
@@ -0,0 +1,5 @@
+Author: Shreya Singh
+Title: BTech Student, Information Technology
+Description: Shreya is a 
+is a Front-End Developer Enthusiast with a strong passion for Java, Python, React.js, Node.js, and RDBMS.
+Shreya enjoys learning tech insights and content from the developer community. In addition to being a developer, Shreya is a learner, explorer, and open-source contributor who finds joy in collaborating on projects.