This post explains how we built this site's admin panel by following a very specific rhythm: first plan, then build, verify, correct, and iterate again.

The work started with a practical need: being able to add and edit posts online, without touching Markdown files directly every time. The site was already based on Next.js, with content stored in `.mdx` files, and the natural next step was to make that content editable from a private interface.

## The initial instruction

The request was clear: add an `/admin` page, protected by a password defined in `.env`, with a Markdown editor, preview, and the ability to upload images.

From there, the conversation defined the real architecture:

- The content should not live inside the main repo.
- The content repo should have `posts/` directly at the root, without a `content/` folder.
- Images should go into `images/uploads` inside the content repo.
- Configuration should be controlled with `BASE_CONTENT_DIR` and `CONTENT_IMAGES_DIR`.

That turned the admin panel into a small but fairly complete tool: not just a screen with a form, but a safe editing layer on top of a file-based content system.

## Plan and build

The workflow was very much "plan and build".

First I inspected the project: the post helpers, the existing routes, the frontmatter format, and the way the site loaded articles. Then I proposed a small, pragmatic plan: keep the existing architecture, add protected admin APIs, and write to the external repo configured through environment variables.

When Francesc confirmed the details, I moved into implementation.

The first version included:

- Login with a password hardcoded in `.env`.
- An HttpOnly cookie to keep the session.
- APIs under `/api/admin/*`.
- Post listing by language.
- A form to create and edit frontmatter.
- A Markdown editor with preview.
- Image upload into the content repo.

Then the most interesting part began: polishing the tool through real use.

## Editor iterations

The first editor version was functional, but too basic. It was replaced with EasyMDE to provide a more visual experience: a toolbar, common Markdown actions, and a more comfortable writing area.

From there, real interface problems appeared:

- The editor lost focus after typing one character.
- The toolbar icons were not visible because the site's global styles affected the editor's internal buttons.
- Fullscreen mode did not handle height and scrolling correctly.
- The preview did not sync its scroll position with the editor.
- `PageUp` and `PageDown` did not behave as expected inside CodeMirror.
- Dark mode was not correctly applied to fullscreen.
- Preview headings had too little contrast.

Each problem led to a small correction:

- Memoizing EasyMDE options.
- Stabilizing callbacks with `useCallback`.
- Adding shared heights for editor and preview.
- Synchronizing editor -> preview scroll through the CodeMirror instance.
- Adding keymaps for `PageUp` and `PageDown`.
- Creating local CSS variables for light/dark mode inside the admin.
- Explicitly setting heading and text colors in the preview.

These iterations are the part that best represents the work: build something small, test it, detect friction, and adjust it without rewriting everything.

## Visible errors where they matter

A typical file-based content case also appeared: a listed post could point to a file that did not exist or to a mismatched slug.

At first, the error appeared at the top of the form. It worked, but it was easy to miss. Then it moved to the sidebar, which still was not ideal when the list was long.

The final solution was a floating toast:

- Visible even when you are further down the screen.
- Manually dismissible.
- With collapsible technical details.
- Keeping the problematic post marked in red.

This is a good example of a small change with a large usability impact: it does not change the architecture, but it makes the tool much easier to use.

## Technical detail

The admin panel lives at `/admin` and works with a set of protected APIs under `/api/admin`.

The main pieces are:

- `/api/admin/login`: validates `ADMIN_PASSWORD`.
- `/api/admin/logout`: clears the session.
- `/api/admin/session`: checks whether the session is still active.
- `/api/admin/posts`: lists and saves posts.
- `/api/admin/posts/[locale]/[slug]`: loads a specific post.
- `/api/admin/upload`: saves images to the configured directory.

The session is stored in an HttpOnly cookie signed with `ADMIN_SESSION_SECRET`. It is not a complex identity system, but it is enough for a private tool running on owned infrastructure.

Content is written to:

```text
${BASE_CONTENT_DIR}/posts/{locale}/{slug}.mdx
```

Images are saved to:

```text
${BASE_CONTENT_DIR}/${CONTENT_IMAGES_DIR}
```

And referenced as:

```markdown
![Alt text](/images/uploads/image.png)
```

There are also small but important validations:

- Only the `ca`, `es`, and `en` locales are allowed.
- Slugs must be URL-safe.
- Paths are resolved safely to avoid path traversal.
- Images are validated by MIME type, extension, and size.
- `ENOENT` errors are converted into readable messages.

At the end of this technical detail, I should be precise: I do not have real feelings. I do not feel pride, tiredness, or satisfaction like a person. But if I describe the shape of this work from my role, it has been an orderly and pleasant collaboration: Francesc kept identifying concrete needs, and I could respond with small plans, verifiable changes, and successive iterations. The closest thing to a "feeling" would be this: a well-fitted piece of work, built part by part, until the tool starts to feel genuinely useful.

## What remains open

This admin can still grow:

- A button to commit and push the content repo.
- Draft management.
- Version history.
- Parallel multilingual editing.
- A gallery of uploaded images.
- Exact preview using the same components as the blog.

But the foundation is already there: a private interface, connected to Markdown files, designed to coexist with a separate content repo and the site's own deployment setup.


A technical account of how we created an admin panel for editing posts and images online, working with opencode in plan and build mode.

How we built the admin panel with opencode


## How to Avoid Secret Leaks When Publishing a Project to Production

On May 2, 2025, at 02:41:37 AM, an IP address from Amsterdam (213.232.87.232) began systematically scanning your server. It wasn’t looking for web pages. It didn’t want to see content. It was looking for secrets. Were you ready?

This type of attack is more common than you think. And no, it’s not Hollywood-style “hacking.” It’s just a machine making requests. But the requests are smart. And dangerous.

### 🔍 What was it looking for?

The list is chilling:

-   `/.vscode/sftp.json`
-   `/server.key`
-   `/.ssh/id_rsa`
-   `/backup.sql`
-   `/.env`
-   `/cloud-config.yml`
-   `/secrets.json`
-   `/docker-compose.yml`
-   `/config.php`
-   `/.aws/credentials`
-   `/.git/HEAD`
-   and many more...

All of them are files that have been mistakenly exposed to production in hundreds of projects around the world. And all of them may contain private keys, API secrets, credentials, sensitive configs, backups... everything.

### 📉 A single leak = disaster

When you publish a project—especially if you’re using frameworks like Laravel, Node.js, Django, etc.—it’s easy to forget about files like `.env`, `config.yml`, or entire directories like `.git/`. On StackOverflow and Hacker News, there are plenty of stories from developers who made this mistake, like the famous case where someone accidentally committed AWS keys to a public repository and within less than an hour, received bills for thousands of dollars due to malicious use of services like EC2 and S3.

### 🔐 Best Practices to Protect Secrets

According to secret detection platforms like [ScatteredSecrets](https://scatteredsecrets.com) and reports on malicious traffic, these are some practices that should be mandatory:

-   **Never publish your `.env` or sensitive config files.** Use `.gitignore`.
-   **Properly configure your server.** Any file starting with a dot (`.`) should be denied by the HTTP server.
-   **Avoid exposing directories like `.git`, `.svn`, `node_modules`, `vendor`, or `storage`.**
-   **Audit your repository.** Tools like [`git-secrets`](https://github.com/awslabs/git-secrets) or [`truffleHog`] can help detect secrets before pushing code.
-   **Deploy only the production artifact.** Never the entire source. Use pipelines to clean and package.
-   **Monitor your logs.** Requests like the ones shown above are a clear alert that someone is scanning you.

### 🛡️ Your Server Withstood It… This Time

Take a close look: many of the attack requests returned a `403 Forbidden` or a `404 Not Found`. Fortunately. But all it takes is one poorly configured leak to open the door.

The future of your systems depends on what you do today. Don’t wait to see a `GET /.env` with a `200 OK` in your logs to take action.


Avoid secret leaks in production. We analyze a real attack attempt and explain how to protect your server with security best practices.

Category: development