G-Cubed G-Cubed model deployment options
G-Cubed models can run on managed cloud servers, in GitHub Codespaces or in a dev container hosted on your own computer or infrastructure. Choose the option that fits the model’s performance needs and your organisation’s security and data-handling requirements.
New users of the public 2R model should follow the 10–15 minute Codespaces recipe. The sections below describe the alternatives and the operational details that do not belong in that short recipe.
Client IT and security teams preparing an internal Python package repository, restricted network or air-gapped deployment should use the Python runtime and dependency inventory. It records the exact Python version and the direct and indirect dependencies for the current G-Cubed package release.
G-Cubed Cloud
Commercial users are normally encouraged to use G-Cubed Cloud servers. They are hosted on Oracle Cloud Infrastructure, sized for the relevant G-Cubed model and accessed through Visual Studio Code (VS Code) in a browser. Contact the G-Cubed team to discuss a managed deployment or migration.
GitHub Codespaces
A GitHub Codespace is a cloud-hosted virtual computer that runs the G-Cubed dev container and presents VS Code in a browser or in the desktop VS Code application. It avoids a local Python and Docker installation.
For the public 2R model, fork the gcubed.com-model-2R repository into your own account before creating a Codespace. The fork gives you a remote repository to which you can push your changes. A private production-model repository must not be forked; create a Codespace directly from the repository to which you have been given access.
Cost and machine size
GitHub accounts include an allowance for Codespaces use, after which charges may apply. Consult GitHub’s Codespaces billing documentation for current allowances and prices.
The default two-core machine is suitable for the public 2R model. Larger G-Cubed models may need a four-core machine with more memory. On the GitHub Codespaces page, use the … menu beside a Codespace and select Change machine type when a larger model needs more capacity.
Persistence and stopping a Codespace
A Codespace is not permanent storage. Commit and push model, data and experiment changes that need to survive deletion or failure. Results are normally excluded from Git because they can be large; download the reports or other results that you need to retain.
When a session is finished:
- save the files you changed;
- commit and push work that must be retained;
- open the Codespaces menu from the blue status-bar button in VS Code;
- select Stop Current Codespace; and
- close the browser tab.
Closing only the browser tab can leave the Codespace running and consuming its usage allowance. GitHub can also delete Codespaces after a period of inactivity, so do not rely on the Codespace disk as the only copy of your work.
Dev containers on your own computer
A local dev container is useful when you need to work offline, use a more powerful computer or keep execution inside your organisation’s infrastructure. It requires VS Code, Git and a suitable Docker environment.
Follow the detailed instructions for your operating system:
The dev-container overview explains the common architecture and links to each installation guide.
Private cloud and self-hosted deployments
The VS Code front end, Linux execution environment and Git data repository can run on different systems. This supports hybrid cloud, on-premises and self-hosted Git arrangements as well as the standard Codespaces deployment. Review the G-Cubed platform and deployment overview when assessing organisation-specific performance, security or information management requirements.
If these options do not address your requirements, contact the G-Cubed team about a tailored deployment.