Why Personal Brand Is Technical Visibility, Not Packaging: My Full Deployment Walkthrough

Six Phases

If divided by phase, this round roughly took six steps.

Phase 1: From Idea to Server

The initial idea was simply to set up a personal blog. But once started, the first step was not writing code but preparing the server environment: buy server, log in, confirm environment, create regular user, configure SSH . These basic environment configurations determined whether later deployment could be stable.

Phase 2: From Server to Domain Entry

The blog could not stay at IP access only. So I bought a domain, went through real-name authentication and ICP filing, handled DNS resolution . This phase turned the blog from "runs locally" to "others can access via a formal entry".

Phase 3: From Accessible to Secure and Controllable

Once services were exposed to the public internet, security became mandatory. I further handled firewall, security groups, root login, database ports, fail2ban . This phase made me realize even the smallest personal project faces security issues.

Phase 4: From Development Environment to Production Architecture Deployment

I considered whether Conda or Docker was more suitable for production, and also debated where to install Nginx. Finally chose Docker to manage production, with Docker Compose plus a global Nginx to manage applications. This phase shifted from "runs" to "reproducible and maintainable".

Phase 5: From Deployment Success to Complete Launch

Blog startup was not enough; still needed to handle SSL certificates, object storage, database migration, admin initialization, static resource access . These details made the blog run more robustly.

Phase 6: From Blog to Lightweight Personal Homepage Entry

After the blog went live, I found it solved content precipitation but not how others quickly understand me. So I started building a personal website and portfolio site, organizing homepage, representative articles, representative projects, blog, WeChat official account, and GitHub into one entry . Here, the whole "deploy yourself to the internet" collection formed its first closed loop.

Five Outcomes

Extracting outcomes from this collection yields roughly five things.

Outcome 1: Completed the End-to-End Launch Path for a Personal Blog from 0 to 1

This is not merely running a blog program, but walking through server, domain, filing, deployment, security, certificates, resource management, and database initialization completely.

Outcome 2: Established a Long-Term Content Position

After the blog went live, content is published not only on third-party platforms but also on the blog. The WeChat official account remains important, but the blog takes on archiving, topic organization, search, and long-term access roles.

Outcome 3: Sorted Out a Personal Server Deployment Methodology

From Conda to Docker, from multiple Nginx containers to a global Nginx, from open ports to security groups and firewalls, clarified the deployment approach suitable for one's own server.

Outcome 4: Wrote the Practical Process into a Series of Articles

If only deploying the blog application, experience would scatter quickly. Writing it into an article collection turns it into reviewable, searchable, shareable content assets that can enter the portfolio.

Outcome 5: Built a Lightweight Personal Website Entry

As articles and projects grew, an entry was needed to link them. Homepage, article entry, project entry, about me — let others more easily understand who 楸木 is, what they have done, and research directions.

Five Problems

The most valuable reflection is not specific commands but the problems encountered and their handling process.

Problem 1: Does Launch Equal Project Running?

Before, launch meant project startup success. After, I found launch includes at least: server stability, domain accessibility, HTTPS normal, database connectivity, static resource loading, port and permission control, subsequent maintainability and migratability. Project running is only step one; true launch is the whole chain working.

Problem 2: Should a Personal Small Server Take Security Seriously?

Answer: Yes . Even a personal blog, once on the public net, gets scanned. Don't run root bare, don't casually open database ports, don't rely only on application security. Firewall, security groups, SSH, fail2ban — these basic actions are not complex; doing them early greatly improves server security.

Problem 3: How to Manage Project Dependencies in Production?

Conda

suits local and some Python environment management scenarios. But for my personal blog deployment, Docker fits long-term maintenance better. It solidifies the runtime environment and aids migration and reproduction. This is not absolute; choose based on your business scenario.

Problem 4: How to Manage Multiple Project Entrances with Nginx?

Initially, I followed the old style of spinning up an Nginx container per project. But as projects grew, domains, certificates, configs, ports scattered. So I adjusted to a single global Nginx managing multiple project entrances. Also not absolute; plan based on your scenario.

Problem 5: Why Still Need a Personal Website After Blog Launch?

Blog solves content precipitation but not necessarily first understanding. A stranger opening the blog may not know where to start or which articles are representative. So I used AI to craft a lightweight website entry explaining projects and linking other application entrances.

Summary

After this round, my problem-solving approach became systematic. Initially I only wanted a simple blog, later discovered blog needs server, domain, filing, deployment, security, certificates, resource management. Together they form a long-term technical position.

Previously I Cared How Commands Execute, Now I Care Why Choose This Way

Why Docker not Conda, why global Nginx, why portfolio site chose Astro. The trade-offs themselves are worth more review than individual steps.

Previously I thought done means end; now clearer: writing down precipitates. If only do without record, soon forgotten.

Previously I Treated Website as Showcase Page, Now See It as Understanding Entry

It organizes blog, articles, projects, and GitHub so others understand me faster. If doing similar projects later, I will reuse this method.

Do real projects first, then talk showcase Don't start with complex personal website Real projects are source of content and works Stabilize infrastructure first. Server, domain, security, HTTPS, deployment method — solid foundation makes projects run longer

Record Reason for Every Technical Choice

Don't just record commands; record why this choice, why abandon another. These become decision-type articles later. Write pitfalls promptly: filing issues, server scans, database initialization, object storage access — annoying at the time, written down become experience.

Articles and Projects Must Interconnect

Projects prove you did it; articles prove you thought it; website organizes them. Three connected, complementary, form personal brand infrastructure. It becomes a programmer's own long-term technical position.

Next article, the series finale, will continue: after completing personal portfolio site, I gained new understanding of programmer personal brand. The whole technical chain reviewed; last piece returns to the programmer: why after all this, I feel personal brand is not packaging but visualization of long-term technical position.