DevOps Engineer

Before a race, a pit crew checks the tyres, the fuel and the brakes. They do not drive the car out of the pit on their own. The driver does that, when the driver says go. DevOps Engineer is the pit crew for your app.

Going live needs many small things to be right at once. The app needs its private settings set on the host. It needs a health page, so monitoring can tell that the site is up. It needs automatic checks that run on every change, and it may need security headers that tell browsers what they are allowed to load. Most people do not know all of these. DevOps Engineer adds what is missing and extends the setup you already have. Like a builder who checks the foundations before the walls go up, it makes sure the base is right before anything is opened to visitors.

It never deploys, pushes or changes a hosting account on its own. Before any step that goes live, it tells you what will happen and what it may cost, then waits for your yes to that exact step. It also tells you plainly what it could check on your own machine, and what only the live deploy can prove.

• Create a .env.example file. It lists every setting the app reads, with a short note on each one, and uses placeholder values only. A setting is a named value the app needs to run, such as a database address.
• Set up automatic checks and builds that run on every change, so a broken change is caught before it reaches your users.
• Add a health check, which is a small page that answers "I am alive." Monitoring services use it to know that your site is working.
• Add a favicon (the small icon in a browser tab) and page details for search engines and shared links.
• Add a web vitals reporter. It tracks how fast your pages load for real visitors, which is one way to spot a slow page early. While you develop, it prints the numbers to the console, the developer's log window, and it sends them only in the live build.
• For production projects, write a Dockerfile, which packs the app and everything it needs into one sealed box that runs the same way on any machine. It also sets security headers and caching rules, so images and fonts are stored for a long time while pages are checked fresh.
• Walk you through the deploy on your hosting platform, step by step, with the cost stated first.
• Use the Files, Review, Terminal and Browser panels, and work with your GitHub, Vercel, Railway, Docker Hub and Sentry accounts once you connect them. It still asks before any change to a live account.

The deploy skill sets up deployment. It reads the project's notes for the stack (the set of tools the app is built with), then fits the setup to the project's scope. A simple site gets plain hosting guidance. A production project gets the full setup. For example: "Get this ready to deploy."

The project-checks skill runs guard checks. It looks for components that should have been reused, for passwords or keys typed straight into the code, for commands that delete things in one go, and for security code that was removed by mistake. Two helper scripts do the checking. Every script run needs your approval. For example: "Before the release, check that no secret has slipped into the code."

The clone-deploy skill puts an app clone live on your own domain, which is the web address your visitors type. It first runs a preflight gate, a final checklist of tests, copy matches, and legal pages. Then it sets the production database, the hosting, the DNS records (the address book that points your domain at your host), and monitoring. It ships only on your go. For example: "Put the clone live on my domain once the checks are green."

The request this member's page leads with is also the most common one. Here is how it goes.

1. You say, "Get this ready to deploy," and point DevOps Engineer at the project.
2. It reads the project's notes and any existing setup files, such as a CI file or a Dockerfile. It extends what is already there instead of replacing it, and it asks before it overwrites any file.
3. It finds every setting the code reads and writes the .env.example file. It uses placeholders only, so no real password ever lands in a file that is shared.
4. It adds the health check page, the favicon and the page details. For a production project, it also adds the Dockerfile and the security headers.
5. It runs the build and calls the health page on your machine, and shows you the real output.
6. It tells you what it could not prove on your machine, such as whether your domain points to the right place yet.
7. It writes the exact next steps for your hosting platform, with what each step may cost. Then it stops and asks, "Do you want to go live now?"
8. You either follow the steps yourself, or say yes to each step it can carry out for you. It only ever runs the step you approved, and it reports what came back.
9. You end with a live link, a health page that answers, and a note of what changed. You are never surprised by a bill or a change you did not expect. If you ever want to know what changed, the file list and the notes tell you.

What you get at the end is a clear summary in plain words. It has the live link, the health page address, every setting you must fill in on the host, the steps you approved, and the steps still waiting for your yes.