Auto-deploy-sap-and-keepalive: one-click proxy nodes on SAP Cloud
Auto deploy sap and keepalive
At a glance
- What is it?
- This repository automates deploying a proxy node to a SAP Cloud account through GitHub Actions, using an Argo tunnel, a WebSocket or XHTTP direct connection, and then keeps the free-trial instance alive with one of three keepalive methods. It is a deployment script, not a proxy client, and everything depends on a SAP account.
- Who is it for?
- Auto-deploy-sap-and-keepalive suits someone who wants a proxy node on SAP Cloud without learning the platform's application lifecycle, since the workflow handles the build, the deployment and the environment variables. It does not suit anyone who needs a guaranteed long-lived server, because the free trial model that makes it attractive is the same model that makes it fragile.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 71 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
What the repository automates
The project automatically deploys an Argo tunnel or a direct node to the SAP Cloud platform. The README states that the trial edition comes with a complete automatic keepalive solution, and that it is adapted for enterprise edition deployment, where no keepalive is needed.
That last sentence is the key to understanding the whole design. The repository exists because a free trial account on a platform like SAP Cloud is not a permanent server, so the two problems are coupled. Deploying is one of them, and keeping the instance from being reclaimed is the other, and the README treats them as a single workflow rather than as two separate tools.
The project is presented as a fork-and-run workflow rather than as a tool you invoke. The steps are: fork the repository, enable the workflows, set the secrets, configure the environment variables, then run a workflow from the Actions page and collect the resulting node details. There is a video tutorial linked from the README, and a Telegram group for feedback.
The top level of the repository is small, which fits a project that is mostly workflow definitions. There is a .github/ directory holding the Actions workflows, a LICENSE file, the README, a _worker-keep.js file for the Cloudflare Workers keepalive, a keep.sh script for the shell-based keepalive, and a kyma.yaml file.
The primary language of the repository is JavaScript, and the topic tags list the protocol family the deployment targets, including sap, trojan, vless-ws-tls, vmess and vmess-ws-tls.
Prerequisites and the two secrets you have to set
Two accounts are required, and the README is explicit about both. You need a GitHub account, because the repository is forked and the deployment runs as a workflow in your own fork. And you need a valid SAP Cloud account, with a registration link provided.
The GitHub requirement exists for a structural reason. The deployment workflow has to run somewhere with a secrets store, a job runner and the ability to push a container image, and a forked repository with Actions enabled is the cheapest way to get all three without the reader operating a build server.
The secrets are simple and sensitive. In the repository settings, under Secrets and variables, then Actions, then New repository secret, you create two entries.
The first is `EMAIL`, the SAP login email for either the trial or the enterprise edition, and the second is `PASSWORD`, the corresponding login password. Both are marked as required.
Those two values are what the keepalive mechanisms use later. The keepalive is a login to the SAP web console, so the credentials are not optional configuration, they are the mechanism. That is a design decision worth naming plainly: a workflow that logs in on your behalf needs a password, and storing it in a GitHub secret is the standard place for it, but it does mean the secret is available to every workflow in the repository, including any you add yourself.
The Docker container environment variables are also set in secrets, which is the fourth step of the deployment instructions, and there is a warning attached to it that matters if you use a fixed tunnel token, since the README says the Cloudflare port should be set to 8001 in that case.
The environment variables that shape the node
The base environment variables decide what gets deployed and where the traffic goes, and the README separates them from the optional ones.
The first group is the base set. `UUID` is the node identifier, and the README attaches a sharp warning to it: if you have enabled Nezha v1, you must change the UUID after deploying one instance, otherwise the agent will be overwritten. `ARGO_DOMAIN` is the fixed tunnel domain, and if it is not set a temporary tunnel is used instead. `ARGO_AUTH` is the fixed tunnel JSON or token, with the same temporary fallback, and it does not exist when a direct image is used. `SUB_PATH` is the subscription token, defaulting to sub.
The optional group covers the monitoring and network preferences. `ARGO_PORT` sets a custom Argo tunnel port, defaulting to 8001. The `NEZHA_SERVER` variable takes the v1 form of a host and port or the v0 form of a bare host, `NEZHA_PORT` is not used in v1, and `NEZHA_KEY` is either the v1 client secret or the v0 agent key. `CFIP` and `CFPORT` set a preferred domain or address and the matching port, and neither exists when a direct image is used. `DOCKER_IMAGE` selects the container image, and it defaults to the Argo tunnel CDN.
Two details are easy to miss. The default subscription path of sub means the subscription address is predictable, and the README's final note recommends setting a subscription token to prevent the node from being leaked. And the CFIP and CFPORT pair, described as a preferred domain or preferred address, is the mechanism for steering around a blocked route, which is the reason a free-trial node on a business platform is being used in the first place.
Running the deployment and finding the node
The deployment itself starts from the Actions page of your fork, where the README names the workflow as the automatic deployment proxy to SAP. You click Run workflow and choose or fill in three parameters.
The type parameter selects the deployment type, with the options being the Argo tunnel CDN, a WebSocket direct connection and an XHTTP direct connection, and the Argo tunnel is the default. The region parameter selects the deployment area, where SG(free) and US(free) are the trial edition and everything else, namely aws, gcp and azure, corresponds to the enterprise edition, and you pick the one matching the platform you opened. The app_name parameter is optional and specifies the application name, and leaving it empty generates a random one.
There is a preparation step that catches people out. The README says that after creating the second region on the trial edition, or creating a region on the enterprise edition, you must create a space with any name, otherwise it will not run. A space is the SAP Cloud organisational unit, and the deployment needs one to attach the application to.
After the run, you open the Actions run and expand the detailed deployment information to see the service link. Visiting the domain and seeing a Hello world page means the deployment worked.
The subscription address is the domain followed by the subscription path, so with the default it is the domain plus sub. That is the address you put into a client, and the README's note about changing the UUID and setting a subscription token are both about making that address hard to guess.
Three ways to keep the free trial instance alive
The keepalive section offers three mechanisms and you pick one.
The first runs from a VPS or a small NAT box. The README recommends using keep.sh for precise keepalive, and the script is downloaded and run locally or on the box.
wget https://raw.githubusercontent.com/eooce/Auto-deploy-sap-and-keepalive/refs/heads/main/keep.sh && chmod +x keep.shThen you edit the variables and the keepalive URL in the first four to eight lines of the file and run it.
bash keep.shThe second is GitHub Actions itself. The README warns that the Actions keepalive may have timing drift, and recommends adjusting the cron time in the automatic keepalive SAP workflow based on what you have observed over the previous two days. That is an admission that the schedule needs tuning against the platform's own reclamation behaviour, and it is a signal that this method is the least precise of the three.
The third is a Cloudflare Worker. You create a worker in the Cloudflare dashboard, paste the contents of the _worker-keep.js file into the editor, add your login email and password at the top, optionally the Telegram notification configuration, plus the project URL and project name, and deploy. Then you add a cron trigger to the worker.
*/2 0 * * *The README explains the expression as checking every two minutes between 8 and 9 in the morning Beijing time. The worker is the most interesting of the three because it needs no machine of your own and the repository ships the code, but it also puts your SAP password into a third-party platform, which is the same credential in a different trust boundary.
Where the deployment script is the wrong approach
The first limitation is that the whole thing rests on a free trial account, and the free trial model is what makes the keepalive necessary. If the platform reclaims the instance, the node goes with it, and the keepalive is a race against a policy that can change without notice. The README's own advice to tune the cron based on the previous two days of behaviour is an admission of that fragility. For anything that needs to be up, a paid instance with no keepalive is the simpler system.
The second is the credential exposure. The SAP password is needed by the keepalive, and there are three places it can end up: GitHub Actions secrets, a script on a machine you own, and a Cloudflare Worker. The GitHub option is the least exposed of the three because the secret is scoped to a repository you control, but the Cloudflare option puts a live account password into a third-party platform and the script option puts it in a file on a server. The README also links to a Telegram group for feedback, which is a channel where people discuss their own working configurations.
The third is the shared subscription model. The default subscription path is sub, and the README recommends changing it precisely because a predictable path on a free trial is a liability. The UUID warning covers the same problem from the monitoring side, since the Nezha agent is overwritten if the UUID is not changed between deployments.
The fourth is the operational opacity. The README is a deployment guide, and it does not describe what the deployed container is, how the tunnel is authenticated beyond the ARGO_AUTH variable, or how to rotate a compromised node other than by redeploying. There is no documentation of the traffic path, no guidance on logs, and no upgrade path for the image, since DOCKER_IMAGE defaults to a CDN reference rather than a pinned version.
The fifth is that the enterprise edition needs none of this, and the README says so. If you have an enterprise account, the keepalive is unnecessary and this repository is a way to skip learning the platform's own deployment model, which is a real but narrow benefit.
Licence, maintenance and the cost of a scripted deployment
The project is under the Apache-2.0 licence, with the LICENSE file at the root of the repository, which is the right choice for a deployment script that people are expected to fork and modify.
The repository is not archived and the last push was on 2026-08-13, so the project is being worked on. There are no GitHub releases, so the workflow definitions in the main branch are the artefact, and a fork is a snapshot of whatever was there when you forked it.
The cost of using it is low in resources and higher in trust. The deployment runs as a GitHub Actions job, so you are spending minutes of runner time, and the container lives on someone else's free trial account. The cost in attention is the keepalive, because there are three mechanisms and each of them needs occasional adjustment, which is the opposite of the hands-off experience the one-click deployment suggests.
What makes the repository worth reading is the shape of the workflow. The whole deployment is a fork, two secrets, a set of environment variables and a manual workflow trigger, and the environment variables are documented with the defaults and the cases where a variable does not apply. That is the difference between a script you can adapt and a black box, and it is why the README is written as a deployment manual rather than as a feature list.
The reading-order recommendation in the README is also sensible: pick one keepalive method rather than all three, and set the subscription path and the UUID before the first deployment, since both are things you have to live with afterwards.
Editorial conclusion
Auto-deploy-sap-and-keepalive suits someone who wants a proxy node on SAP Cloud without learning the platform's application lifecycle, since the workflow handles the build, the deployment and the environment variables. It does not suit anyone who needs a guaranteed long-lived server, because the free trial model that makes it attractive is the same model that makes it fragile. Set the subscription path and the UUID before you deploy rather than after, since a node whose address is guessable is a node you will have to rotate.
Frequently asked questions
What does Auto-deploy-sap-and-keepalive do?
It automatically deploys an Argo tunnel or a direct node to SAP Cloud through a GitHub Actions workflow, and it provides keepalive methods so the free trial instance is not reclaimed. The enterprise edition needs no keepalive, and the trial edition comes with a complete automatic keepalive solution.
How do I deploy with Auto-deploy-sap-and-keepalive?
Fork the repository, enable the workflows, add the EMAIL and PASSWORD secrets for your SAP account, set the Docker container environment variables, then run the automatic deployment workflow from the Actions page, choosing the type, region and optional app name. After creating a second region you must also create a space, otherwise it will not run.
Which keepalive methods does the project support?
Three. A keep.sh script run on a VPS or a small NAT box, a scheduled GitHub Actions workflow whose cron time the README says may need adjusting, and a Cloudflare Worker built from the _worker-keep.js file with a cron trigger such as */2 0 * * *. You choose one.
What environment variables does the deployment need?
The base set is UUID, ARGO_DOMAIN, ARGO_AUTH and SUB_PATH, where the Argo variables fall back to a temporary tunnel when unset and the subscription path defaults to sub. The optional set covers ARGO_PORT, the NEZHA_SERVER, NEZHA_PORT and NEZHA_KEY monitoring variables, the CFIP and CFPORT preferred route, and DOCKER_IMAGE.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/eooce-auto-deploy-sap-and-keepalive)Was this useful?