# You push, your VPS updates itself You pick the repository and the branch, and the panel clones the code onto the VPS, creates the webhook on GitHub and gets everything ready. From there, every push to that branch triggers a pull, runs your build and restart scripts, and records which commit was deployed. It's the flow of a Vercel-style platform, on a server where you have root and the price doesn't depend on how much traffic you get. URL: https://ardumaker.com/en/servicios/deploy-github/ - Webhook created for you - Build and restart scripts - Commit history ## Here's what it looks like in the panel Real screenshots of the ArduMaker panel, not mockups. ![GitHub deploys: Deploy from GitHub](https://ardumaker.com/screenshots/servicios/deploy-github-1.jpg) **Deploy from GitHub**. Branch, last sync and every pull with its steps and duration. ![GitHub deploys: Build scripts](https://ardumaker.com/screenshots/servicios/deploy-github-2.jpg) **Build scripts**. What runs before and after each pull, with templates. ## Pick the repository and it's published In Apps a deploy is a single step: you pick the repo and the platform does the rest. Everything it sets up is visible in the VPS and you can change it. - It detects the project: Node.js, static site (Vite, React, Astro, HTML), Python (Django, FastAPI, Flask) or a Dockerfile. - Before deploying it shows how it will build, how it will serve and where nginx points, with what it detected already filled in. You confirm it or change it. - It gets an automatic https address; add your own domain later from Domains. - Every push to the chosen branch redeploys. - If something fails, it says at which step and takes you to the server tab where the log is. ## Before you install it ### Use it when - You have a website, an API or a front end in a GitHub repository and want it published with HTTPS without configuring a server. - You want every push to a branch to update what is published, without using SSH. - The project is Node.js, a static site (Vite, React, Astro, HTML), Python (Django, FastAPI, Flask) or ships its own Dockerfile. ### It's not the right fit if - You only need a database or Redis: those have their own apps. - The application is already published as an image in a registry: deploy it with Docker. - You need several services starting together (app, queue, database): use Docker with a Compose file. ### How to check it's working 1. **Open the address it was given**: When it finishes, the app shows its https address. Open it in the browser or run: curl -I https://your-app.arducloud.com — it should answer 200 (or whatever redirect your app does). 2. **Make a change and push it**: Change some text, git push to the deployed branch and reload the page: the change shows up when the deploy finishes. Each deploy's log is kept in the VPS, Deploy tab. 3. **If it's an API, call an endpoint**: curl https://your-app.arducloud.com/health (or your own route). A 502 means the app didn't start: check the service log in the VPS. ### Tips - Before deploying you see how it will be built, how it will be served and where nginx points. Review it: fixing it there is faster than fixing it later. - Your app must listen on the port it receives in the PORT variable, not on a fixed one. - A static site leaves no process running: nginx serves the built folder (dist, build or out). - Environment variables and secrets belong in the VPS, not in the repository. - The automatic domain is good to get started; add your own later from Domains, with its certificate. ## A complete deploy pipeline, no YAML The convenience of a Vercel-style platform, on a server that's yours. - **Link the repo from the panel**: You pick a repository from your GitHub account, the branch and a project name. The branch is checked to exist before the deploy is created. - **Automatic webhook**: The webhook is created for you on GitHub, with SSL verification. There's nothing to touch in the repository settings. - **Pull on every push**: Every push to the tracked branch triggers a git pull on the VPS. Pushes to other branches are ignored. - **Scripts before and after**: A pre-pull script (which discards local changes by default) and a post-pull one to install dependencies, build or restart services. - **Visible status**: Cloning, pulling, building, restarting, online, or error with the message. You know where each deploy stands. - **Commit history**: Every commit received is recorded with its SHA, message, author, date and the files added, deleted and modified, with a link to GitHub. - **Manual redeploy**: Deploy again with a button when you need to, without making an empty commit. - **The whole app in one place**: You associate the repo's domains, systemd services and scheduled tasks with it, and see the whole application together. - **Several branches, one VPS**: The same repo can be deployed on different branches within the same VPS: production and staging side by side. - **No YAML to maintain**: There's no pipeline file to break when the syntax changes. Two shell scripts, which is what ends up running anyway. - **No build minutes**: The build runs on your VPS. No minute quota and no runner queue: the limit is the CPU you're already paying for. ## Your first deploy in minutes 1. **Connect your GitHub account**: Once, from the panel. 2. **Pick a repo and a branch**: The code is cloned onto the VPS and the webhook is created for you. 3. **Define build and restart**: For example npm ci && npm run build, and restarting your service. 4. **Publish it with a domain**: You assign a domain with HTTPS and every push updates it. 5. **Check the history**: Every deployed commit is kept with its SHA, author, message and changed files. If something broke, you know exactly with what. ## How it works underneath, and what to keep in mind What you should know before you start, no fine print. - There's no runner and no CI agent: the GitHub webhook notifies the VPS and the VPS runs git pull on the clone it already has. That's why a deploy takes as long as your build and nothing more. - The pre-pull script discards local changes by default. That's on purpose: a file edited by hand on the server is the most common reason a pull fails in the middle of a deploy. - The post-pull script is where everything of yours goes: installing dependencies, building, migrating the database, restarting your app's systemd service. - Pushes to other branches are ignored. The same repository can be deployed on different branches within the same VPS, so production and staging coexist without stepping on each other. - Each repository-and-branch combination is deployed once per VPS. - It needs systemd running on the VPS. It's verified in production on Ubuntu 22.04 and compatible with 18.04, 20.04, 24.04 and 26.04; it isn't available on 16.04, because systemd 229 won't start on a host running cgroup v2. - You need the GitHub account linked with a valid token. If the token expired right as you deleted a deploy, the webhook can be left hanging on GitHub and you have to delete it by hand. - The build runs on the VPS and uses its memory. On the smallest plan, keep the repository light: building something big runs out of memory halfway through. - Company administrators edit and delete deploys; members can view and create them. - Real root over SSH: the panel is a shortcut, not a cage. Anything it does with a button, you can also do by hand. ## Or just ask Claude, ChatGPT or Cursor Everything you see in the panel, your AI agent can do through the ArduMaker MCP server: with your authorization, within the scope you grant, and with every action audited. [See what the MCP does](https://ardumaker.com/en/mcp/deploy/) ## GitHub deploys: frequently asked questions ### Do I have to set up the webhook on GitHub? No. It's created automatically when you link the repository. ### What happens if I push to another branch? It's ignored. Only the configured branch triggers the pull. ### Can I build and restart my app after every deploy? Yes, with the post-pull script: you install dependencies, build, and restart your app's systemd service. ### Can I see what was deployed and when? Yes. Every commit is recorded with author, message, date and changed files, with a link to GitHub. ### Does it work as an alternative to Vercel or Heroku? For apps you want to run on a server of your own, yes: you get the same push-to-deploy flow, but with root, no function limits and the VPS's fixed price. ### Do I need to write a pipeline file? No. There are two shell scripts: one before the pull and one after. There's no YAML to break when the platform's syntax changes. ### How long does a deploy take? As long as your build takes. There's no runner queue and no CI minutes: the webhook notifies, the VPS pulls and runs your script. The CPU is the one you're already paying for. ### Can I have production and staging on the same VPS? Yes. The same repository can be deployed on different branches within the same VPS, each with its own scripts and its own domain. ### What if I edited a file by hand on the server? The pre-pull script discards local changes by default, precisely because that's the most frequent reason a deploy gets stuck. If you need different behavior, that script is yours to edit. ### Can I deploy again without making a commit? Yes, with the redeploy button. You don't need an empty commit to force the pull. ### Which frameworks does it detect on its own? When you install the repo from Apps, its files are read and a way to build and start it is suggested: a Dockerfile runs as a container; Next.js, Nuxt, Remix, Express, NestJS and SvelteKit (node) build with npm and start on port 3000; Vite, Astro, Create React App and static SvelteKit build and serve their output folder; Django, FastAPI and Flask install requirements.txt and start with gunicorn or uvicorn. It is a suggestion: you confirm it or change it. ### How do I deploy a Django or FastAPI app? Link the repo and the branch. With manage.py it detects Django and starts it with gunicorn; with fastapi in requirements.txt or pyproject.toml, FastAPI starts with uvicorn on port 8000. Environment variables and the command are set in the deploy configuration, the app runs as a service that restarts on its own, and the domain gets automatic SSL. ### Can I host my own MCP server or an agent that runs 24/7? Yes. A remote MCP server or an agent is a Node or Python app like any other: deploy it from GitHub, give it a domain with HTTPS and it keeps running as a service, with no execution time limit. If it has a Dockerfile, it runs as a container. ## Services that go well together Everything runs on the same VPS and is managed from the same panel. - [Domains and SSL](https://ardumaker.com/en/servicios/dominios-ssl/): A free subdomain or your own domain with Let's Encrypt, an nginx proxy with rollback, and port forwarding. - [Services and scheduled tasks](https://ardumaker.com/en/servicios/servicios-y-tareas/): Create systemd services for your app and cron-style scheduled tasks with logs, without writing systemctl. - [Docker](https://ardumaker.com/en/servicios/docker/): Enable Docker in one click and manage images, containers, logs, volumes and networks from the panel. **From push to production, on your own server** Link your repo and let every commit deploy itself. Not a separate product: it's in the panel of every ArduMaker VPS, right next to real root over SSH. [See plans](https://ardumaker.com/en/precios/)