From Idea to ICP Filing: How I Built the Entry Layer of My Personal Blog

This is the ninth post in the "Deploying myself to the Internet" series, marking the completion of the first segment: turning the desire for a personal blog into a basic entry layer.

Although the blog is not yet deployed—no Docker Compose, Nginx, or HTTPS—the author has resolved the pre‑deployment questions of why the blog is needed, what it should achieve, where it will reside, how users will reach it, and who is responsible.

If these questions are not clarified early, later tasks such as server security, deployment, certificates, and object storage become fragmented. Therefore, this post is a stage review rather than a showcase of new technology.

The author records the real process, listing the steps taken so far:

Buy a server

Buy a domain

Complete ICP filing

Configure security

Plan Docker deployment

Integrate Nginx and HTTPS

Future work will extend the blog into a personal website and portfolio.

The series does not teach personal branding tricks; instead, it documents how a programmer builds a long‑term technical base from zero to one.

The first eight posts confirmed the blog’s value, defined the direction of a technical brand, distinguished personal blog, tech blog, portfolio site, and personal homepage, then proceeded to purchase a server, acquire a domain, understand real‑name verification, ICP filing, DNS resolution, and finally fill out the filing form.

At this point the blog is still offline, but the entry layer has a clear outline: the server provides hosting, the domain provides an access point, and the filing ensures compliance. Together they transform the blog from a local project into a system ready for the public internet.

Looking back, this stage completed four things

Why have a personal blog.

The blog is viewed as the foundation of a personal tech brand, complementing public accounts (for distribution), portfolios (for showcasing projects), and personal homepages (as a unified entry). Each serves a distinct role rather than replacing the others.

Why build a technical brand.

After publishing a Git collection, the author realized that without organizing and expressing technical ability, achievements remain hidden in work experience. A technical brand becomes an evidence chain—articles, projects, code, retrospectives, and tech choices all serve as proof for others.

Prepared basic resources.

A cloud server was purchased, with careful consideration of long‑term maintenance costs—not just CPU and memory, but renewal fees, bandwidth, disk, backup, migration, security, and cognitive overhead. Long‑term sustainability often depends more on willingness to maintain the project after the first months than on initial launch success.

Connected domain and filing.

Buying a domain prompted thinking about a lasting entry point; real‑name verification, filing, and DNS parsing clarified domain‑related concepts; filling the filing form reminded the author that launching a blog involves technical, entity, responsibility, and compliance aspects.

The biggest shift was conceptual: the blog is no longer just a place to post articles but a long‑term system for hosting technical content, project practice, and personal branding.

If the site were only a page, visual appeal would suffice; if only an article list, publishing capability would matter. As a system, considerations expand to deployment location, domain, compliance, security, maintainability, and future extensibility into a homepage or portfolio.

This stage also hit several cognitive pitfalls

First pitfall: wanting to launch quickly.

Rushing to get a project running leads to technical debt: unresolved server permissions, chaotic directory structures, unclear security groups and firewalls, open database ports, mismatched domain and filing information, and Nginx configurations that are hard to extend. These issues surface as the project grows.

Second pitfall: treating filing as a pure process.

Although filing lacks code‑like error messages, it forces the author to clarify the site’s purpose, name, responsible party, domain ownership, and server location—essential for a clear personal brand.

Third pitfall: seeing the domain only as a tool.

Choosing a domain influences long‑term positioning; the domain may appear in public accounts, GitHub, resumes, portfolios, and READMEs, so it should be stable and reflect future content direction.

Practices distilled

First: set goals before picking tools.

Do not get stuck on server specs, domain suffixes, or filing fields before understanding what you are building. Simple article sites need lightweight solutions; a long‑term technical base requires more control, stability, and extensibility.

Second: consider long‑term cost before short‑term discounts.

First‑year offers on servers, domains, and cloud resources are tempting, but a personal blog is intended to run for years; unsustainable costs must be avoided.

Third: ensure consistency before chasing expressive flair.

Especially for domain, filing, and site positioning, accuracy, realism, and consistency outweigh catchy names or grandiose descriptions that could become unmaintainable.

The next phase will focus on server security. After purchasing the server, the author will address security before deploying the blog, because the machine will be publicly exposed for the long term.

Before deployment, the author must decide whether root login can remain enabled, how to create regular users, whether SSH needs adjustment, the division of responsibilities between security groups and firewalls, which ports to open, why database ports should not be exposed, whether fail2ban is needed, and how to monitor server health. These considerations, though not directly about personal branding, determine whether the technical base can operate stably over time.

Thus, from idea to filing, this stage delivered not a single page but the foundational infrastructure that moves the project from “I want a blog” to “I have begun building a real, maintainable technical platform.”

The next article will detail the challenges encountered during the filing process and provide a reference for readers.