Introduction
I'm already used to having AI write my code. I handle the design myself, and I leave the implementation to Claude. That's my usual style.
However, I used to think that the work of deploying what I created—putting it on my home server—was something I had to do with my own hands. Building images with Docker, pulling them on the server side, placing the SQLite DB outside the container, configuring the .env file, setting up permissions. It's tedious and boring, but I assumed it had to be manual work.
That’s what I firmly believed.
The Limits of Copy-Paste Consultation
In the past, when trouble occurred on the server, I would copy and paste terminal output to ask an AI.
It was a nightmare when I installed Nextcloud on my home server. Errors kept popping up regarding permissions, and I consulted GPT-5.4, but it just went in an endless loop. "Try changing the permissions for this directory" -> I changed it -> Another error -> "Then try this one" -> I changed it -> Back to the original error.
I eventually resolved it with Claude's help, but it took a considerable amount of time.
"Shall I write a script for you?"
This happened when I was deploying a Discord auction bot to my home server.
After updating the container a few times, Claude asked me: "Shall I write a script to make updating the container easier?"
I told it to go ahead.
First, it started by setting up SSH key authentication. It handled key generation and registration to authorized_keys on the server side. After setting up an environment where I could perform remote operations without a password, it created deploy.sh.
Before that, I was manually typing commands into a remote terminal. If an error occurred, I had to try again, and I was checking if it worked by copying and pasting logs. It was a hassle.
The contents of deploy.sh are simple. It builds the Docker image locally, pushes it to the GitHub Container Registry, enters the server via SSH, runs podman pull (the server runs BazziteOS, so I use podman instead of Docker), stops and removes the old container, and starts a new one. It handles the DB volume mounts and .env loading all in one go. Now, this is all finished with a single script execution.
Furthermore, when the bot threw an error during startup later on, Claude checked the server logs via SSH, identified the cause, fixed the code locally, and redeployed it with deploy.sh. Everything was completed in a single session.
The Difference Between Copy-Pasting and Direct Access
Back when I was just consulting via copy-paste, the AI couldn't see the server's status. Even if I passed it the error messages, I was stuck manually ruling out possibilities one by one—like "Is this a user error?" or "Is the environment configuration wrong?" It was inefficient because I was essentially acting as a middleman.
Giving Claude SSH access allows it to check the server's status with its own "eyes." It can act based on facts rather than speculation.
All it's really doing is executing ssh user@host "command" from Bash. There’s no special mechanism involved. As long as key authentication passes, from Claude's perspective, it’s just a "slightly distant terminal."
Some might ask if that’s scary, but I only have SSH and port 80 open, and it's an environment without any revenue at stake. Besides, Opus understands the intent behind my instructions accurately, so I’m not worried about it running any reckless commands. I imagine if I were using a less precise model, I might feel differently.
Conclusion
I was convinced that deployment was manual labor. It never even occurred to me to delegate it until Claude asked me, "Shall I write a script for you?"
