Open a Site — Get a Next.js Project on Disk

Not long ago, I needed to restore the interface of a marketing website whose source code had vanished along with the contractor. More precisely, the client only had a production link left. In the past, I would have spent an evening copying the layout manually, but this time I came across a project that does it in a minute. And not via LLM, which was unexpected for me.

What is ditto.site

ditto.site — an open source TypeScript compiler that takes a public URL and turns it into a self-contained project. By default it outputs Next.js App Router, on request — Vite React. Styles come via Tailwind or plain CSS.

Let me clarify what the author means by "cloning". There's no git clone here: you don't need the site's repository or its source code. You only need a link accessible from a browser. The tool opens the page, records what the browser actually rendered, and writes a new project from that.

The author explicitly calls their system a "capture-to-code pipeline" and emphasizes that the compiler is not an LLM that authors pages. The same captured copy always produces byte-for-byte identical output. By the way, determinism is marketed as the main feature here, and that's more honest than mysterious neural network generation where each run differs.

The project already has 1580 stars and 214 forks on GitHub, MIT license. The project is new, but the community around it is forming quickly.

How to use it

Three ways. The simplest is the local CLI:

git clone https://github.com/ion-design/ditto.site.git
cd ditto.site
npm ci
npx playwright install chromium
npm run clone -- https://example.com/ --out=./output

After installing Chromium, the npm run clone command opens the page, captures the state, and places the ready application in output/<site>/app. I liked this detail: without the --out flag, results go into runs/<site>/<timestamp>/, and the symlink runs/<site>/latest always points to the latest clone. Scripts don't need to be rewritten for the new timestamp.

There are lazy modes too:

npm run clone -- https://example.com/ --serve   # клонирует и сразу поднимает dev-сервер
npm run clone -- https://example.com/ --open    # плюс открывает браузер

The second way is a REST API at api.ditto.site. Create a key through the form or curl with email verification, export it to DITTO_API_KEY, and launch a task:

curl -sS -X POST "$DITTO_API_URL/v1/clones" \
  -H "authorization: Bearer $DITTO_API_KEY" \
  -H "content-type: application/json" \
  -d '{
    "url": "https://example.com/",
    "options": {
      "mode": "single",
      "styling": "tailwind",
      "framework": "next"
    }
  }'

The response includes a file map with each file's path, size, and SHA-256. Their CLI unpacker helps extract the directory tree to disk, and the entire project can be downloaded as a single archive via /bundle?format=tgz.

The third way is an MCP server, and honestly, this is the most interesting part for me. ditto.site connects to agents as a regular MCP tool, and the server is designed to be economical: first the agent receives only the task ID and metadata, and reads files as needed. Tools like clone_website, list_clone_files, and read_clone_files allow the agent to launch a clone itself, wait for completion, and selectively read package.json or a specific component.

What ends up in the generated project

The output is not just layout. According to the README, the application includes:

• restored pages and route modules;
• captured assets, fonts, icons, manifests, and metadata;
• robots, sitemap, llms.txt, and JSON-LD if detected;
• small runtime helpers for recognized interactions and animations;
• generated AGENTS.md and ARCHITECTURE.md for handing off the project.

I'll note the last point separately. The author clearly expects a human or AI agent to work on the code afterward, and immediately includes instructions on which files are safe to edit: src/app/content.ts and src/app/components/. This is a rare level of care for a generator.

How it works internally

The pipeline looks like this: URL → browser capture → normalized intermediate render → deterministic output → application generation → asset materialization → optional validation.

Capture writes the DOM, computed styles, layout boxes, source CSS, fonts, screenshots, and interaction states. Reproducible animations are also captured if observable. However, arbitrary third-party JavaScript, authentication, payments, and personalization are not reproduced. This is a logical limitation: the tool works with what is visible in the browser, not server-side logic.

The repository has solid architecture: compiler, Hono REST API alongside MCP server, Drizzle schema with migrations, task queue worker, artifact storage for S3/R2. You can spin up everything locally via docker compose with Postgres and MinIO, or run a simplified inline mode without a database in one command. There's also an MCP endpoint at localhost:8787/mcp for the local API.

I like that there are verify and asyncVerify options: the generated project can be run through validation and you get confirmation that it at least builds and renders similarly to the original.

Where it comes in handy

The first scenario is obvious: restoring a site when there are no sources. An abandoned landing page, lost contractor sources, a legacy page that needs to be moved to a modern stack. Here the tool solves the problem in minutes.

The second scenario is prototyping. A client shows "I want it like here" and drops a link. Instead of abstract discussions, you get a working project with Next.js structure in a couple of minutes, and then discuss differences within it. For a freelancer estimating work scope from someone else's reference, this speeds up the start.

The third scenario is automation via MCP. An agent can be tasked: "clone this site as a Next.js app, wait for completion, read the generated files". The "only needed files" format saves the agent's context, and the authors clearly thought this through.

The other side and rules of the game

There are caveats. The CLI currently lives inside the repository and isn't published to npm, so npx ditto won't work — you need to clone the entire repository. This isn't something you can add to CI with a single line, but the authors honestly warn about this.

Then there's the ethics. The README constantly reminds you: only use the tool where you have the right to copy and transform content. Phishing, brand impersonation, authentication bypass, and mass capture of other people's sites are explicitly prohibited, and the project has a separate document RESPONSIBLE_USE.md. That sounds right: the technology itself is neutral, but it's worth applying it to your own projects or with the owners' permission.

One more thing. In both Russian and English, the word "cloning" sounds bold, but in reality it's a reconstruction of the visible part of the page. Don't expect the tool to pull out server-side code, a database, or business logic — it honestly states this in the README.

Who should try it

If you build landing pages, migrate sites to a new stack, or want to give an AI agent a clean tool for working with web interfaces, take a look at ditto.site. Start with the local CLI, it doesn't require keys: npm run clone -- https://example.com/ --serve, and in a couple of minutes you have a dev server running on the restored project. And if you want to bolt this into your pipeline, the REST API and MCP server are already included. For a designer or tech lead who often receives "make it like this", the tool looks like an honest answer to a very common pain point.