Pipi Engines to build, deploy and manage in the cloud

Mike's Notes

Finally got onto this job. Should be fun. 😊

Resources

• https://www.blog.ajabbi.com/p/pipi.html
• https://www.blog.ajabbi.com/2025/10/industry-workspace.html
• https://www.blog.ajabbi.com/2025/10/using-free-tiers-on-cloud.html
• https://www.blog.ajabbi.com/2024/12/comparison-of-open-source-configuration.html
• https://www.blog.ajabbi.com/2025/11/plugins-revisited.html
• https://wiki.ajabbi.com/eng/9/engines.html
• https://www.blog.ajabbi.com/2025/11/using-github-actions-to-cli-jfrog-aws.html
• https://www.adventuresincre.com/data-center-development-model/

References

• Reference

Repository

• Home > Ajabbi Research > Library >
• Home > Handbook > 

Last Updated

30/11/2025

Pipi Engines to build, deploy and manage in the cloud

By: Mike Peters

On a Sandy Beach: 30/11/2025

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

The problem

The open-source workspaces under development are designed to be shared on GitHub/GitLab and hosted in production on various Cloud Platforms. Eventually, private cloud and on-prem will be included, as long as Pipi 9 can get secure access. In that case, hybrid clouds should also be fine.

Pipi 9 needs to be able to automatically build, deploy, and manage this process, either directly or via third-party tools such as GitHub Actions.

Agent Engines

An early Pipi 6 module from 2016 that catalogued cloud services was converted to a Pipi 7 microservice in 2018. Yesterday, this was imported into Pipi 9 and is being used to create these agents, which act as autonomous engines.

• Platform Engine (plt) - this one is the commander on the battlefield. I will get this finished first.

A dedicated agent engine has been created for each cloud platform.

• Apple Engine (ale)
• AWS Engine (aws)
• AZURE Engine (azu)
• Digital Ocean Engine (dgo)
• Google Cloud Engine (ggc)
• IBM Engine (ibm)
• Meta Engine (met)
• Oracle Engine (ora)
• (More will be added later; all are welcome)

Then I remembered: Pipi 9 also has some self-deployment capacity, so generalising the existing capacity for building, deploying, and managing to share with the other engines makes sense. They have yet to be differentiated.

• Pipi Engine (pip) - for deploying to the closed data centre in a Boxlang/JRE host environment.

How

Most agents start like a Stem Cell. They are then modified to perform a specific job and can evolve over time. That's what I'm doing now.

I started last night with the GCP console, looking at how to reverse-engineer the APIs and make a data model to drive the API calls. Looks straightforward. Gemini 3 chat is a big help and is saving a lot of time.

But wait, there's more

Each agent engine is complex and can incorporate other agents like LEGO bricks. Example: API Engine (api). Just as in a living biological cell, everything is structured, in flux and self-regulating in response to its environment and internal processes. Other agent types, like primitives, are not complex.

Free-tier experiments

The Engines will play in the free tier of the different cloud providers. Probably try using GitHub Actions first, using the discovered sample code and go from there.

Known available free tiers (more to come)

• Alibaba Cloud
• AWS
• Azure
• Cloudflare
• Container Hosting Service
• DigitalOcean
• Google Cloud
• Hetzner Cloud
• IBM Cloud
• Linode
• Netlify
• OpenShift
• Oracle Cloud
• OVHcloud
• Render
• Salesforce
• Tencent Cloud
• Vercel
• Wasabi
• Zeabur

Cost $$$$$$$ 😎😎

The free-tier usage limits need to be locked to prevent Pipi from burning through lots of cash.

Cloud credits

If Ajabbi can get some cloud credits, then playing with the more expensive stuff would be possible to make sure everything works for future customers. It would enable customers to choose their preferred cloud provider without barriers.

No Series B

Ajabbi is a bootstrap start-up for public good (with a future foundation) and will have no investors, so there will be no Series B. Unfortunately, these cloud providers are obsessed with giving more credits only to Series B start-ups. Go figure.

Stock numbers

Use more cloud engines as the load increases. So if, for example, IBM Engine (ibm) can handle 1,000 enterprise customers, and 10.000 enterprise customers want IBM cloud setups, then Platform Engine (plt) can get the Factory Engine (fac) to breed more IBM Engine (ibm) to nibble on the work. I won't know the actual stocking ratio until field testing under load. But whatever it is, it won't be a problem. And it may turn out that some very large customers need a dedicated cloud engine each. All of these are possible.

Developer Accounts

The Workspaces for Developers, currently under development, will enable developers to help configure these cloud engines and keep them up to date. This will also enable any platform to add itself by submitting a request for a dedicated cloud engine and its devs, helping with the config and user documentation.