How to Launch an Astro Blog on aidrop.it

From the team behind aidrop.it — one workspace to build, host, and keep changing your code.

A static Astro blog can go live as one small web service: keep posts in Git, build them into HTML, and serve the output at a public HTTPS address. Your first release should include a homepage and one real article. Your second release proves that publishing another post is repeatable.

You need a coding agent with a shell and Git, a connected aidrop.it account, and a Project with capacity for one Service. Follow the connection quickstart, then give the agent the brief below. This walkthrough keeps articles and images in the repository; it needs no database.

1. Build a blog with one real post

Start with a homepage, an article template, and one Markdown post. Give the agent your blog name, a short description, and the actual text you want to publish. A real article reveals layout problems that a placeholder hides: long headings, links, code blocks, images, and how the page reads on a phone.

Ask the agent to start from Astro's blog template, keep static output, and commit the dependency lockfile. Check the title, description, date, and URL of the first article. The Astro deployment guide describes the production build: npm run build writes the site into dist by default.

Run that build locally and inspect the generated pages. A development server answering requests is only the first check; the files that will ship must contain the intended content. Deploy your first AI-built app gives a broader brief for that first release.

2. Serve the production build

Deploy a container that serves the generated files with a production static server. Keep the build stage separate from the runtime stage, so the running service contains only the site and its server. Test a direct visit to an article URL, because readers will often arrive without opening the homepage first.

Ask for a multi-stage Dockerfile that installs locked dependencies, builds Astro, and copies dist into the runtime image. Configure the server to listen on 0.0.0.0:8080, log to stdout, and operate with a read-only root filesystem. Any temporary files must use the runtime's scratch directories.

Push the repository, then have the agent call service_build with these settings alongside the Project, Service name, and repository reference:

{
  "build_type": "dockerfile",
  "build_dockerfile_path": "Dockerfile",
  "runtime_kind": "static_site",
  "container_port": 8080,
  "health_path": "/"
}

The Dockerfile path must be named in the build call. A Dockerfile nobody names does nothing explains that setting. The agent polls service_get, reads logs if the build stops, and checks the returned public URL after success.

3. Connect your domain and publish again

First verify the site at its assigned address, then connect a custom domain if your plan supports one. A domain changes where readers find the blog; publishing changes the files it serves. Check both separately, including the canonical URLs and feed links generated during the build.

On aidrop.it, ask the agent to call service_domain_add for your hostname. Create the DNS record it returns and have the agent run service_domain_verify. Set Astro's site configuration to your final HTTPS origin, rebuild, and verify the homepage, article, and RSS feed if included.

Now add a second Markdown post, commit, push, and ask the agent to build the same Service again. Confirm that the new article appears in the index while the original URL still works. This is the publishing workflow you will repeat; writing files inside the running container would lose that history.

A launch brief you can reuse

Give this brief to your coding agent with your first article attached or already in the repository. Replace the placeholders and verify the resulting pages yourself. Keep the checklist in the repository so future releases preserve the details that matter to readers, including working links and usable mobile layouts.

Launch a static Astro blog in Project <project>.
Blog name: <name>
Description: <one sentence>
First article: <path to Markdown file>
Final domain, if available: <hostname>

Create a homepage, article template, and RSS feed.
Keep posts and images in Git. Use static output and locked dependencies.
Build dist in a Dockerfile; serve it with a production static server.
Listen on 0.0.0.0:8080 and use / as the health path.
Support a read-only root filesystem and log to stdout.
Push, deploy, and report the commit and public URL.
After domain setup, rebuild with the final site origin.

VERIFY EACH RELEASE
[ ] Homepage and article open directly over HTTPS.
[ ] Article title, date, description, and images are correct.
[ ] Mobile layout is readable; no horizontal overflow.
[ ] Canonical URLs and RSS links use the intended origin.
[ ] A nonexistent article returns 404.
[ ] A new post appears without breaking an older URL.

FAQ

Does an Astro blog need a database? A static blog with repository-based posts does not. Comments, accounts, or saved form submissions require additional application behaviour and somewhere to keep their data.

Can my agent publish each new post? Yes. With aidrop.it connected, the agent can commit and push your Markdown changes, call service_build for the existing Service, and check the resulting article URL.

Should I run the development server in production? Use the production build and a server configured to serve its output. Keep the development server for local editing and feedback.