We created our own on-premises virtual appliance - called Jidoteki Meta - designed to build on-premises virtual appliances.
Here’s an overview of the current features:
Console boot GUI
Before you can access an on-premises appliance, you’ll need a way to configure the network settings. This basic console boot GUI provides a menu for managing those settings prior to accessing the web UIs.
Admin UI and API
A simple open source Admin UI and API can be used to monitor the appliance’s health, to manage network and security settings, and to apply system updates. The REST API allows you to automate tasks using Jenkins or other tools of your choice.
Jidometa UI and API
The Jidometa UI and API are not (yet?) open sourced. They use the same core as the Jidoteki Admin API, but provide additional API endpoints and a separate UI for creating and managing builds, and other settings. Of course, it’s also possible to automate the entire build process thanks to the REST API with tools such as Jenkins.
Integrations with Slack
We’ve only scratched the surface of what’s possible with Jidometa (Jidoteki Meta). We’ve recently included a Slack integration which allows the build status to be pushed to your Slack channel. When a new build is created, when the status changes, when the download files are ready, you’ll know about them right away, and can download them directly from the Slack channel UI.
More to come
We’ve got quite a few more features planned for the near future. We’re really happy that our customers can now maintain full control of their entire on-prem virtual appliance builds, in their own local environment. Of course, we’re glad to continue providing support for one-off builds and custom requests.
Why did we do this?
One of the biggest issues our customers faced with the Jidoteki service, was the turnaround time for creating/downloading/testing updates and new OVAs. Our servers hosted in Tokyo introduced additional delays for downloading files which were occasionally between 500MB and 1GB. Being a fully-managed service meant we also had to be available to create the builds on our customer’s behalf.
In the early days, we provided Jidoteki as a SaaS for our customers to use on their own. The transition to fully-managed directed us to use the SaaS on their behalf, but the SaaS service still meant our customers relied on our infrastructure to be available 24/7.
Going on-prem
Making Jidoteki available as a on-prem appliance was a logical and obvious decision on our end. It provides the benefit that our customers can create and manage their builds independently from us (i.e: without relying on our availability). It also completely eliminates file download latency, since the appliance runs in their own local private network, behind their firewall. For us, it means we can focus exclusively on Jidoteki and supporting customers, rather than managing a complex and resource-intensive production infrastructure.
The biggest benefit though, is that we’re dogfooding our own product. By having our own on-prem appliance, our customers directly benefit from having the latest updates and improvements, since our customer appliances, and our Jidometa appliance share the same base OS and packages. If there’s an issue, we’re the first to know and test it on Jidometa, and we can quickly move those changes upstream to our customer’s appliances.
Get started
We’ve been doing this Jidoteki thing for over 4 years (plus my time working on GitHub Enterprise). I’m confident to say that we’re experts at this, and our constant iterations on Jidoteki have greatly helped us progress and provide better and better solutions for going on-prem.
If you’re interested in providing secure, offline, on-premises and easily updateable virtual appliances to your enterprise customers, please contact us to discuss your situation. We’ve converted desktop software, bash scripts, SaaS, and even installers over to the virtual appliance format.00
Our setup fee starts at USD $995 (depends on your requirements), and we’ll be more than happy to discuss your needs and requirements.