https://github.com/c100k/rebootx-on-prem Skip to content Toggle navigation Sign in * Product + Actions Automate any workflow + Packages Host and manage packages + Security Find and fix vulnerabilities + Codespaces Instant dev environments + Copilot Write better code with AI + Code review Manage code changes + Issues Plan and track work + Discussions Collaborate outside of code Explore + All features + Documentation + GitHub Skills + Blog * Solutions For + Enterprise + Teams + Startups + Education By Solution + CI/CD & Automation + DevOps + DevSecOps Resources + Learning Pathways + White papers, Ebooks, Webinars + Customer Stories + Partners * Open Source + GitHub Sponsors Fund open source developers + The ReadME Project GitHub community articles Repositories + Topics + Trending + Collections * Pricing Search or jump to... Search code, repositories, users, issues, pull requests... Search [ ] Clear Search syntax tips Provide feedback We read every piece of feedback, and take your input very seriously. [ ] [ ] Include my email address so I can be contacted Cancel Submit feedback Saved searches Use saved searches to filter your results more quickly Name [ ] Query [ ] To see all available qualifiers, see our documentation. Cancel Create saved search Sign in Sign up You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert {{ message }} c100k / rebootx-on-prem Public * Notifications * Fork 0 * Star 38 * RebootX On-Prem is an open source specification for defining a custom server in order to manage on-premise runnables in the RebootX app. c100k.eu/p/rebootx License Apache-2.0 license 38 stars 0 forks Branches Tags Activity Star Notifications * Code * Issues 1 * Pull requests 0 * Actions * Security * Insights Additional navigation options * Code * Issues * Pull requests * Actions * Security * Insights c100k/rebootx-on-prem This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository. master BranchesTags Go to file Code Folders and files Name Name Last commit Last commit message date Latest commit History 26 Commits .github .github data data impl/http-server-go impl/ http-server-go spec spec .eslintrc.cjs .eslintrc.cjs .gitignore .gitignore .prettierrc.cjs .prettierrc.cjs CONTRIBUTING.md CONTRIBUTING.md LICENSE LICENSE README.md README.md cover.png cover.png docker-compose.yml docker-compose.yml package.json package.json tsconfig.json tsconfig.json yarn.lock yarn.lock View all files Repository files navigation * README * Apache-2.0 license RebootX On-Prem CI What is RebootX On-Prem? RebootX On-Prem is an open source specification for defining a custom server in order to manage on-premise runnables in the RebootX app. A Runnable is anything that runs, can be stopped and rebooted. For instance, Virtual Machines (VMs), Dedicated servers, Containers, PaaS Applications, Databases... are all valid concretions of a runnable. If you have already used the RebootX app, you are already familiar with how it works when you connect public cloud providers like Amazon Web Services (AWS), Microsoft Azure, Clever Cloud, Google Cloud (GCP), OVH or Scaleway. [cover] Why should you use this specification ? It provides the solution if you are in one of these cases : * You have servers in your local network that you want to manage via an app * You hack around small devices like the Raspberry Pi and you want to manage it via an app * You have dedicated servers in a datacenter that do not have a central administration console and you want to manage them via an app Of course, these are only examples and the only limit is your imagination. Getting Started The specification is as simple as the following endpoints : list, reboot, stop. Of course, it will evolve overtime. It follows the OpenAPI Specification allowing a high level of compatibility with existing tools. You can play with it by loading it locally in SwaggerUI with Docker Compose: # Generate swagger.json (optional since it's already present in the repository) docker run --rm -v $(pwd):/app oven/bun run /app/spec/generate-swagger.ts yarn lint # Generate Go code with OpenAPI Generator docker run --rm \ -v $(pwd):/app \ openapitools/openapi-generator-cli:v7.4.0 generate \ -i /app/spec/_generated/swagger.json \ -g go \ -o /app/impl/http-server-go/vendor/openapi # Run Swagger UI calling the Go server docker-compose up You can then access http://localhost:9002 via your browser and test the endpoints. See docker-compose.yml to have the apiKey. You can also directly test the server with cURL: curl -v -H "Authorization: " http://localhost:9001/cd5331ba/runnables curl -v -X POST -H "Authorization: " http://localhost:9001/cd5331ba/runnables/self/reboot curl -v -X POST -H "Authorization: " http://localhost:9001/cd5331ba/runnables/self/stop Creating your own server You can develop your own server to fit your personal needs and keep control on everything that runs on your infra. As long as you respect the specification, you can use the language of your choice. To speed things up, you can generate some code using OpenAPI Generator. For instance, you can generate Rust code with the following command : docker run --rm \ -v $(pwd):/app \ openapitools/openapi-generator-cli generate \ -i /app/spec/_generated/swagger.json \ -g rust \ -o /app/impl/http-server-rust/openapi Although it can be handful, we do not recommend relying on all the generated code for a production server, because it contains too much boilerplate, making it harder to maintain. It's fine to use the generated structs, interfaces, enums, traits, though. That being said, it's up to you. Once ready, your server should get your runnables from a local file, another API, network calls or a database (remote or local). Once again, it's up to you. It should be deployed to an independent location, accessible by the phone you want to use : Internet if you want access from anywhere / LAN if local access is enough for your use case. Of course, except in some cases, you must serve it with HTTPS to secure the connection between the app and your server. Implementations HTTP Server Go This is the implementation used in the docker-compose command above, made in Go. You can browse the code at impl/http-server-go. If you don't want or cannot build your own server, you can use this one. You can download the latest release from the releases page or build it yourself from source. The server can run in different modes depending on your use case : * noop (default) : it does nothing except returning empty payloads * self : it returns the host as a runnable. Be careful if you run this on a machine as a privileged user. It relies on syscall and exec so it can actually reboot or stop the machine for real * fileJson : it reads the runnables from a JSON file that must respect the schema in order to be unmarshalled into an array of Runnable (see servers.example.json) To override the default behavior, see docker-compose.yml or config.go and update the appropriate environment variables accordingly. Contributing We welcome all kind of contributions to show examples in other languages. Feel free to reach out to us or to publish a PR. It must be clean and self contained in its own directory in ./impl. Please read the CONTRIBUTING.md guide first. About RebootX On-Prem is an open source specification for defining a custom server in order to manage on-premise runnables in the RebootX app. c100k.eu/p/rebootx Topics infrastructure cloud server on-prem Resources Readme License Apache-2.0 license Activity Stars 38 stars Watchers 1 watching Forks 0 forks Report repository Releases 4 tags Packages 0 No packages published Languages * Go 60.8% * TypeScript 32.4% * JavaScript 6.8% Footer (c) 2024 GitHub, Inc. Footer navigation * Terms * Privacy * Security * Status * Docs * Contact * Manage cookies * Do not share my personal information You can't perform that action at this time.