[{"content":"Telcos and regional providers have a real opening in sovereign AI, but raw compute is not enough. Customers may care about locality, jurisdiction, and control, but they still need a usable way to build, deploy, and operate software.\nAI makes that gap more visible. If software can be created faster, the bottleneck moves to the platform that runs it.\nThe missing software layer A sovereign AI software layer gives customers the primitives and workflow needed to turn local infrastructure into applications. That usually means application hosting, serverless functions, object storage, databases or key-value storage, messaging, secrets, CI/CD, local development, deployment and rollback, and identity controls.\nThe provider still sells infrastructure. The difference is that customers can do something useful with it faster, without giving up the control story that made them choose a local or sovereign provider in the first place.\nWhat the layer should package The software layer should package the repeated work customers do after buying compute.\nThat includes creating projects, connecting code repositories, building services and websites, handling routes and domains, managing secret references, exposing storage and messaging, running local environments, deploying with a reviewable path, and giving support teams enough visibility to help.\nFor a provider, packaging these capabilities matters because customers do not buy infrastructure in isolation. They buy a way to get software running.\nWhy compute gets commoditized Compute is important, but many buyers compare it through a narrow lens: price, region, bandwidth, hardware type, reliability, and support.\nThose matter. They do not automatically create a daily developer workflow.\nModern software teams want a path from code to running app. AI teams also want a path from model-enabled work to controlled deployment. If a provider offers only raw infrastructure, the customer still has to bring Kubernetes, CI/CD, secrets, observability, deployment patterns, model access rules, and platform knowledge.\nThat is a big ask, especially for teams already trying to adopt AI-assisted development.\nThe provider support problem Without a software layer, providers often inherit support questions without owning the workflow.\nA customer asks why their app will not deploy. The provider can see the server is healthy, but the problem is really in Kubernetes, CI/CD, DNS, secrets, or app configuration. The customer still blames the platform experience.\nA better software layer gives the provider a clearer support surface. It does not make every application issue the provider\u0026rsquo;s responsibility, but it gives both sides a shared model for common platform work.\nThat is especially important for smaller and regional providers. They cannot win by copying every hyperscaler feature. They need a focused path that makes their infrastructure easier to consume.\nWhy AI raises the bar AI changes customer expectations. If a team can generate or modify software faster, it will look for a faster path to run that software.\nThe bottleneck moves from writing to shipping. Can the app be tested locally? Can it be deployed safely? Can the provider support controlled infrastructure needs? Can the customer avoid building a large platform team? Can the workflow support humans and coding agents?\nProviders that answer those questions have a stronger story than providers that only rent capacity.\nQuestions providers have to answer A provider product team should be able to answer:\nWhat is the first useful app a customer can deploy? How long does it take from account creation to running software? Can customers test locally before deployment? How are domains, TLS, secrets, and storage handled? Can the platform support regulated or local-control requirements? What does support inspect when a deployment fails? Can AI-assisted workflows use the same path as human developers? These questions turn \u0026ldquo;developer experience\u0026rdquo; from a slogan into a product requirement.\nPackaging mistakes to avoid The weak packaging move is to expose a large catalog of infrastructure services and call it a platform.\nCustomers still have to assemble the workflow. They still have to decide how code moves, how environments are created, how secrets are handled, and how deployments are reviewed. A long menu can make the provider look capable, but it does not always make the customer faster.\nA stronger package starts with a working path. A customer should be able to create a project, connect code, run locally, deploy a website or function, add storage or messaging, and inspect the running workload without assembling a platform from scratch.\nThat path gives the provider a story sales can explain and support can debug.\nWhere sovereignty and AI matter Gartner\u0026rsquo;s public sovereign cloud research points to growing demand for local and sovereign cloud infrastructure. For providers, that is also a product opportunity.\nCustomers with residency, jurisdiction, or control needs still want a modern developer experience. They do not want to choose between \u0026ldquo;use a global platform with a great workflow\u0026rdquo; and \u0026ldquo;use a local provider with raw infrastructure only.\u0026rdquo;\nThe software layer closes that gap.\nThe stronger provider story is not \u0026ldquo;we have servers in the right place.\u0026rdquo; It is \u0026ldquo;we can help you build and run AI-enabled software under the control boundaries you need.\u0026rdquo;\nHow Taubyte fits this provider model Taubyte\u0026rsquo;s public model is relevant to providers because it can sit above infrastructure and expose application primitives to customers. That lets a provider offer more than compute while keeping infrastructure under provider or customer control.\nFor developers, the value is a coherent path to applications.\nFor providers, the value is differentiation.\nFor organizations using AI-assisted software workflows, the value is a grounded route from local work to running software.\nBuild, buy, or partner? Providers need a developer platform capability, but building every layer in-house is not the only path. The real requirement is to offer customers a controlled, usable application layer above compute.\nRelated reading Sovereignty Without Sacrifice: Software Delivery on Infrastructure You Control Sovereign Cloud vs On-Prem vs Customer-Controlled Infrastructure Deploying Your Own Taubyte Cloud with SporeDrive What Is Taubyte in 2026? A Practical Guide for Teams Sources Gartner: sovereign cloud IaaS spending forecast Gartner: Platform Engineering That Empowers Users and Reduces Risk SoftBank: Telco AI Cloud vision Proximus: sovereign cloud provider for European institutions OpenAI: Introducing apps in ChatGPT and the new Apps SDK DORA: State of AI-assisted Software Development 2025 ","permalink":"/blog/posts/software-layer-for-telcos-and-hosting-providers/","summary":"Telcos and regional providers can turn local infrastructure into a stronger AI story when they package a usable software layer above raw compute.","title":"Telcos Need a Sovereign AI Software Layer, Not More Raw Compute"},{"content":"Grounded AI development means AI-assisted code stays connected to the real environment: the runtime, resources, configuration, identity, secrets boundaries, and deployment path. The goal is simple. Generated code should be tested against the world it has to run in.\nWithout grounding, AI can produce code that is plausible and still wrong.\nGrounding means the real system can push back Grounding is context with consequences.\nIt means more than adding text to a prompt. It is giving the AI workflow access to the real system shape: which functions exist, how routes are exposed, how storage is addressed, how messaging works, how secrets are referenced, what build commands run, what deployment expects, and what production will reject.\nThe context has to be close enough to reality that mistakes show up early.\nA grounding map for generated code When an AI coding agent changes software, the review should map the change against the real environment.\nUse this simple map:\nArea Question Runtime Where does this code execute? Configuration Which config changes travel with it? Data What storage or database shape does it assume? Messaging Does it publish, subscribe, or wait on events? Secrets What sensitive values does it need, and how are they referenced? Identity Who or what is allowed to call it? Deployment How does this move from local work to production? Failure What happens when a dependency is missing or slow? This map is not heavy process. It is a way to catch the boring mistakes that generated code often makes.\nWhy prompt-only context breaks down Large prompts can carry a lot of information, but they are still snapshots. They can be stale, incomplete, or too generic.\nSoftware systems are full of details that matter: resource names, permissions, network behavior, build output, runtime limits, data shape, error handling, and versioned configuration.\nIf those details do not exist in the agent\u0026rsquo;s working environment, the model has to infer them. Sometimes it guesses well. Sometimes it makes a confident mess.\nAnthropic\u0026rsquo;s Model Context Protocol is one public example of the industry moving toward more connected AI systems. The direction is right: AI tools need structured ways to reach the systems where context lives.\nWhy local grounding matters The best time to catch an integration problem is before the change leaves the local workflow.\nIf a coding agent can run the app against a production-shaped local environment, it gets feedback from the system. A missing route, bad secret reference, failed build, or wrong resource assumption can show up while the change is still cheap to fix.\nThis is different from asking the model to be careful. Carefulness helps, but the environment has to provide checks. The platform should make bad assumptions visible.\nGrounding still needs guardrails More context is not automatically safer.\nIf an AI system can reach tools and data, teams need boundaries. OWASP\u0026rsquo;s LLM and agentic AI guidance is useful here because it treats prompt injection, sensitive information disclosure, supply chain issues, and excessive agency as practical risks.\nFor development workflows, that means scoped tool access, review before external actions, no plaintext secrets in prompts, logs that explain what happened, tests before merge, and rollback paths after deployment.\nGrounding and guardrails belong together.\nWhat reviewers should look for When reviewing AI-generated code, ask:\nDid the agent inspect the relevant configuration as well as code? Did it run a meaningful local check? Did it introduce new data or secret assumptions? Did it change deployment behavior? Does the diff explain how to verify the change? Are failures observable? Can this be rolled back cleanly? These questions are simple, but they move the review away from style-only feedback and toward production behavior.\nWhat changes when grounding is done well When grounding is done well, review conversations become more concrete.\nInstead of asking whether the generated code \u0026ldquo;looks right,\u0026rdquo; reviewers can ask what the local runtime proved. Did the handler start? Did the route resolve? Did storage behave as expected? Did the build produce the same artifact the deployment path expects? Did the agent leave notes about anything it could not verify?\nThat is a better review loop. It gives humans evidence, and it gives agents feedback they can use in the next change.\nGrounding also helps documentation. If the platform has a clear project model, examples can show real resources instead of abstract boxes. That is useful for developers, and it makes the material easier to trust.\nWhere Taubyte fits Taubyte\u0026rsquo;s local-first workflow is useful because it gives generated code a production-shaped place to run before production. The agent can work against actual platform primitives instead of a loose description of them.\nThat can include websites, functions, storage, messaging, secrets, builds, and deployment workflow. The value is not that AI becomes perfect. The value is that the environment has enough shape to push back when generated code is wrong.\nContext is not the same as grounding Context is information the AI can use. Grounding is context tied to a real system that can verify or reject the work. For coding agents, grounding usually means local runtime parity, real project configuration, executable tests, and a deployment path that matches production.\nRelated reading Why Coding Agents Need a Production Harness, Not Just a Better Model Dev/Prod Parity Is Back Because Coding Agents Believe Local Environments Run a Real Cloud Locally with Taubyte Dream Secrets in the AI Era: Where Plaintext Lives Sources Anthropic: Introducing the Model Context Protocol Anthropic documentation: Model Context Protocol OWASP Top 10 for LLM Applications OWASP GenAI Security Project: Top 10 for Agentic Applications ","permalink":"/blog/posts/grounded-ai-development-real-environment/","summary":"Grounded AI development means generated code is built and checked against the environment it will actually run in, not an abstract prompt-only version of the system.","title":"Grounded AI Development: Keeping Generated Code Connected to the Real Environment"},{"content":"The next fight in developer tools is not about which editor has the best chat panel. It is about the environment around the agent.\nA coding agent can already read files, change code, run commands, and explain a diff. That is useful. It is also a narrow view of software. Real applications depend on configuration, secrets, routes, storage, messaging, builds, deployment rules, and runtime behavior. If the agent cannot see enough of that world, it will fill in the blanks.\nThat is why \u0026ldquo;agentic development environment\u0026rdquo; is a better frame than \u0026ldquo;AI editor.\u0026rdquo; The editor is where a lot of work starts. The environment is what keeps the work honest.\nThe editor is too small a boundary Most AI coding tools are still experienced through an editor or terminal. That makes sense because code is the most visible artifact. But production software is not a pile of files.\nAn agentic development environment has to understand the common primitives that make an application real: functions and services, websites, object storage, databases or key-value storage, messaging, secrets, builds, deployment, local development, and the production runtime.\nWhen those primitives share one model, the agent has less room to invent. The human reviewer also has a better chance of understanding what the agent touched.\nWhat agents need from the environment Coding agents need an environment that can answer operational questions. What kind of resource is changing? How is it configured? What depends on it? How does it run locally? Which tests matter? How will it be deployed? Where do secrets and environment values come from? What should a human review?\nIf the environment cannot answer those questions, the agent has to infer too much. That is where confident but broken changes come from.\nA useful environment gives the agent a map. The agent still needs review. But the review can focus on the work instead of correcting basic assumptions about the platform.\nWhy this is showing up now The public direction is easy to see. Anthropic\u0026rsquo;s Model Context Protocol is about connecting AI systems to tools and data in a structured way. OpenAI\u0026rsquo;s Apps SDK points at AI experiences that can act through real application surfaces. Microsoft has been talking about agent workspaces and isolated agent identities. The pattern is not subtle: agents are moving from text boxes into controlled environments.\nFor software development, that means the environment becomes part of the product. The coding agent needs repo context, but it also needs runtime context. It needs tests that mean something. It needs permission boundaries. It needs a way to leave a handoff that a human can trust.\nThis is where a lot of teams will discover that their developer workflow is held together by memory and tabs. An agent will not know the convention that only lives in one person\u0026rsquo;s head.\nWhat a workspace should not become An agentic development environment should not become a giant black box.\nIf developers cannot see how a change maps to code, configuration, builds, and runtime behavior, the platform is hiding too much. That is a problem for humans, and it is worse for agents.\nGood environment design keeps important state inspectable. Source changes should be visible. Configuration should be versioned or reviewable. Local behavior should be reproducible. Deployment should have a clear path. Failures should point to something concrete.\nThe point is not to remove all complexity. The point is to put complexity where the team can reason about it.\nWhen the environment matters most The environment matters most when a team has many small changes moving through the system.\nThat can happen because the company is growing. It can happen because more teams are shipping internal tools. It can happen because coding agents are making it cheaper to propose changes. In all of those cases, the platform has to absorb more work without turning every change into a custom operations exercise.\nAn agentic development environment helps by giving repeated work a repeated shape. The same ideas show up across projects: create a resource, connect code, test locally, review the change, deploy, and operate it. Once humans and agents understand that shape, each new change starts with less ceremony.\nThis is where the idea becomes practical. It is not a brand category. It is a way to reduce the number of different systems a team has to mentally load before it can ship.\nWhy this is different from a dashboard A dashboard can be useful, but it is not the source of truth by itself.\nFor software teams, the better pattern is reviewable change, reproducible state, local work that resembles production work, deployment tied to versioned changes, and platform primitives that are understandable from code and configuration.\nThat is why Git-centered workflows matter. They make change visible and recoverable. An agentic environment should preserve that property rather than hide important decisions behind clicks.\nHow Taubyte fits this model Taubyte\u0026rsquo;s public workflow combines local development, Git-native configuration, and cloud primitives such as functions, websites, storage, messaging, secrets, and CI/CD. That makes it relevant to agentic development because the agent is not working against files alone.\nFor humans, that reduces the number of separate concepts needed to ship an app.\nFor coding agents, it gives the agent a more complete system to inspect and modify. The agent can work in the same environment where the app will eventually run, instead of producing code for a platform it cannot see.\nWhat the workflow has to show Ask a practical question: can a new service move from local work to deployed software without a tour of unrelated systems?\nA strong agentic development environment should show:\nWhere the code lives. Where the platform configuration lives. How a local environment starts. How storage, messaging, websites, and functions are represented. How builds run. How deployment is reviewed. How the running workload can be inspected. If the answer requires five dashboards and three undocumented conventions, the environment is a set of integrations. The agent will feel that fragmentation immediately.\nThe real test The real test is whether the environment can keep agent work connected to the system that will run it.\nCan the agent inspect configuration, run a meaningful local check, see the resource model, leave a reviewable diff, and explain what it could not verify? If yes, the environment is doing useful work. If no, the team is still relying on a model to guess its way through production.\nRelated reading Prompt-to-Production Is Not App Generation Dev/Prod Parity Is Back Because Coding Agents Believe Local Environments Taubyte Explained: Own Your Cloud with Git-Native Workflows Understanding Taubyte\u0026rsquo;s Built-in CI/CD System Real-Time Messaging with Pub/Sub in Taubyte Sources Anthropic: Introducing the Model Context Protocol Anthropic: Effective context engineering for AI agents OpenAI: Introducing apps in ChatGPT and the new Apps SDK Microsoft Developer: The secure, open platform for AI and agents Gartner: Platform Engineering That Empowers Users and Reduces Risk ","permalink":"/blog/posts/agentic-development-environments-for-coding-agents/","summary":"AI coding agents need more than files and autocomplete. They need an agentic development environment with runtime context, tests, platform primitives, and a path to production.","title":"Agentic Development Environments Need More Than an Editor"},{"content":"Sovereign cloud, on-prem, and customer-controlled infrastructure are related ideas, but they answer different questions. On-prem asks where the infrastructure sits. Sovereign cloud asks which legal and jurisdictional constraints apply. Customer-controlled infrastructure asks who controls the runtime, operations, and portability of the software.\nUsing the right term helps teams choose the right platform.\nQuick definitions On-prem means infrastructure runs in facilities owned or directly managed by the organization, or in a dedicated environment treated like an extension of that organization.\nSovereign cloud means cloud infrastructure and operations are designed around sovereignty requirements such as data residency, jurisdiction, local law, national policy, or critical infrastructure constraints.\nCustomer-controlled infrastructure means the customer has meaningful control over where workloads run, how the platform is operated, and how portable the system remains over time.\nThese can overlap, but none of them fully replaces the others.\nComparison table Term Main question Typical driver What it does not guarantee On-prem Where does it run? Physical control, legacy systems, direct operations Good developer experience or legal sovereignty Sovereign cloud Which jurisdiction and governance rules apply? Residency, public sector, regulated data, local law Low operational burden Customer-controlled infrastructure Who controls the runtime and portability? Ownership, auditability, cost control, exit options A specific physical location This table is intentionally plain. Most bad infrastructure discussions start when teams use one of these terms to mean all three.\nWhy the terms get confused The confusion comes from old cloud debates. For years, the choice was presented as public cloud versus on-prem. That framing is too small now.\nA team might want customer control without owning a data center. A government workload might need sovereign handling but still run with a regional cloud provider. A company might self-host for cost and portability, not because of regulation.\nModern infrastructure choices are more about control boundaries than labels.\nExample scenarios A small software company may want customer-controlled infrastructure because it wants portability and predictable operations. It may not need on-prem or sovereign cloud.\nA government department may need sovereign cloud because jurisdiction and data residency are formal requirements. That does not automatically mean every system has to be operated in a government-owned data center.\nA manufacturer may need on-prem for a plant floor system with limited connectivity. That does not automatically make the platform sovereign, and it does not automatically solve developer workflow.\nA regional provider may offer infrastructure in a specific country and still need a better software layer above compute before developers can use it productively.\nThe terms overlap, but the buying motion changes depending on which problem is real.\nHow to choose the right term Ask these questions before choosing terminology:\nIs the main issue physical location? Use on-prem or hosted. Is the main issue law, jurisdiction, or data residency? Use sovereign cloud. Is the main issue operational ownership and portability? Use customer-controlled infrastructure. Is the main issue avoiding vendor lock-in? Talk about portability and control directly. Is the main issue AI governance? Talk about data access, tool permissions, auditability, and runtime boundaries. This keeps the conversation specific.\nHow to write requirements without confusion Good requirements are concrete. Workloads must run in named regions. Data must not leave a defined jurisdiction. Platform operations must be auditable. Secrets must not be exposed to application code or prompts. Changes must be reviewable in Git. The platform must support local testing before deployment. The organization must be able to move workloads later.\nThose statements are better than saying \u0026ldquo;we need sovereign\u0026rdquo; and hoping everyone means the same thing.\nWhy wording changes the buying conversation The terminology also matters in procurement.\nSomeone searching for \u0026ldquo;on-prem cloud platform\u0026rdquo; may be focused on physical deployment. Someone searching for \u0026ldquo;sovereign cloud platform\u0026rdquo; may be focused on jurisdiction and compliance. Someone searching for \u0026ldquo;customer-controlled cloud infrastructure\u0026rdquo; may be focused on ownership, portability, and avoiding lock-in.\nThe problem is that internal documents often blur those terms together. A buyer writes \u0026ldquo;sovereign\u0026rdquo; when the real issue is data residency. An engineering team writes \u0026ldquo;on-prem\u0026rdquo; when the real issue is operational control. A finance team writes \u0026ldquo;private cloud\u0026rdquo; when the real issue is exit cost.\nClear language makes the decision less political. It lets a platform team say which requirement is real, which one is optional, and which one would add work without reducing risk.\nWhy AI changes the control question AI-assisted workflows connect code, prompts, tools, data, and deployment systems. That makes control more concrete.\nIf an AI assistant can read internal docs, edit code, call tools, or trigger actions, teams need to know what data the assistant can access, what tools it can call, how actions are reviewed, where logs live, whether secrets can leak into model context, and who can disable or constrain integrations.\nOWASP\u0026rsquo;s work on LLM and agentic application security is useful because it treats AI systems as software systems with permissions, supply chains, outputs, and failure modes.\nHow this applies to Taubyte Taubyte\u0026rsquo;s public positioning fits best under customer-controlled infrastructure. The point is not simply \u0026ldquo;on-prem.\u0026rdquo; The point is a software delivery model where teams can build, test, ship, and run on infrastructure they control.\nThat may matter for sovereignty. It may also matter for cost control, portability, developer experience, or long-term operational independence.\nThe more precise the language, the easier it is to explain why a team would care.\nThe practical rule Use \u0026ldquo;on-prem\u0026rdquo; when the physical hosting model is the main point. Use \u0026ldquo;sovereign cloud\u0026rdquo; when compliance, jurisdiction, or residency is the main point. Use \u0026ldquo;customer-controlled infrastructure\u0026rdquo; when the main point is operational control, portability, and ownership of where software runs.\nRelated reading Sovereignty Without Sacrifice: Software Delivery on Infrastructure You Control Why Security and Data Sovereignty Are Driving Companies Toward Self-Hosting What Is Taubyte in 2026? A Practical Guide for Teams Taubyte vs Traditional Cloud Workflows: What Teams Actually Care About Sources Gartner: sovereign cloud IaaS spending forecast Microsoft: Sovereign Private Cloud scales with Azure Local European Commission: AI Act enters into force NIST AI Risk Management Framework OWASP Top 10 for LLM Applications ","permalink":"/blog/posts/customer-controlled-infrastructure-vs-on-prem-vs-sovereign-cloud/","summary":"Sovereign cloud, on-prem, and customer-controlled infrastructure overlap, but they are not the same. The differences matter when teams choose a delivery model.","title":"Sovereign Cloud vs On-Prem vs Customer-Controlled Infrastructure"},{"content":"Sovereignty without sacrifice means teams can use modern software delivery patterns without giving up control over where software runs, where data resides, and how the platform is operated. It is not the same as saying every workload must run on-prem.\nThe better question is: which parts of the system must stay under your control, and can your delivery workflow support that without becoming painful?\nSovereignty is about control, not nostalgia In cloud discussions, sovereignty usually points to legal, geographic, operational, or political control. It can include data residency, jurisdiction, local provider requirements, auditability, and limits on foreign dependency.\nCustomer-controlled infrastructure is related, but it is broader. A team may want control for cost, portability, security, or operational independence even when no formal sovereignty rule applies.\nThose terms should not be blurred. Sovereignty is about control under legal or jurisdictional constraints. Customer-controlled infrastructure is about who can operate, inspect, and move the system.\nWhy this is getting more attention Gartner has forecast strong growth in sovereign cloud infrastructure spending, with governments, regulated industries, critical infrastructure, energy, utilities, and telecommunications among important buyers.\nThe EU AI Act also puts more attention on governance, risk management, and transparency around AI systems. That does not mean every company needs a sovereign cloud. It does mean more companies need to understand where their software runs, how data moves, and who can act on their systems.\nAI makes the question sharper. If coding agents and AI workflows touch code, data, tools, and deployments, then infrastructure control is no longer just an operations topic. It becomes part of software governance.\nThe control layers that matter Sovereignty discussions often collapse into one question: where are the servers?\nThat is too narrow. Teams should separate data control, runtime control, operations control, and governance control. Data control is about where data is stored, copied, logged, and processed. Runtime control is about where software executes and who can change that runtime. Operations control is about who can observe, restart, update, or disable the system. Governance control is about which policies, audits, laws, and approvals apply.\nDifferent teams care about different layers. A financial institution may care deeply about audit trails and data movement. A public sector team may care about jurisdiction and local operating authority. A software company may care mostly about portability and vendor independence.\nPutting all of that under the word \u0026ldquo;on-prem\u0026rdquo; hides the real requirements.\nThe sacrifice teams want to avoid The common fear is simple: if we control more infrastructure, we lose speed.\nThat fear is reasonable. Traditional self-hosting can push teams into custom Kubernetes operations, hand-built CI/CD, manual secrets handling, inconsistent local environments, slow onboarding, complex upgrades, and a permanent platform support burden.\nNobody wants to trade a hyperscaler problem for a staffing problem.\nThe common mistake: control as a location decision Location matters, but location alone does not create control.\nA workload can run in a local facility and still be hard to audit. It can run in a private environment and still depend on fragile manual deployment. It can satisfy a residency rule and still be painful for developers.\nThe useful question is more precise: can the organization govern the software lifecycle? That means code review, configuration review, secrets handling, runtime ownership, deployment repeatability, incident response, and exit options.\nThis is where modern delivery platforms have to earn trust. They need to preserve the workflow quality teams expect from cloud platforms while giving control-sensitive organizations fewer external dependencies.\nWhat modern controlled delivery should provide A modern controlled delivery platform should offer local-to-production parity, Git-centered change history, built-in application primitives, repeatable deployment, secure secrets handling, clear operational boundaries, and enough automation that control does not become toil.\nThis is the practical layer between \u0026ldquo;use a public cloud for everything\u0026rdquo; and \u0026ldquo;build the whole platform yourself.\u0026rdquo;\nHow AI changes the sovereignty checklist AI-assisted development adds new questions. What context can the AI system read? Can prompts or logs contain sensitive data? Which tools can an agent call? Can generated changes be traced to a review? Can the platform limit what an agent can modify? Does local testing expose the same controls production will enforce?\nThese are not science fiction questions. They are ordinary governance questions applied to a faster software workflow.\nRed flags during evaluation Watch for vague answers.\nIf a platform says it is sovereign but cannot explain data movement, admin access, audit logs, deployment control, or exit options, the claim is too thin. If it says it is self-hosted but still depends on a remote control plane the customer cannot govern, that needs scrutiny. If it says it supports AI workflows but cannot explain tool permissions or prompt and log boundaries, the risk has moved rather than disappeared.\nGood controlled delivery should be boring to verify. The vendor or internal team should be able to show where data lives, how changes move, who can act on the system, and how the organization leaves if it needs to.\nWhere Taubyte fits Taubyte is relevant because its public model is built around running software on infrastructure the customer controls while preserving a developer workflow that feels closer to a modern platform.\nThat makes it a fit for teams that want ownership without turning every application into an infrastructure project.\nThe point is not that every team needs sovereignty. The point is that teams with control requirements should not have to give up a sane path from development to production.\nSovereign cloud is not the same as on-prem On-prem describes where infrastructure is physically operated. Sovereign cloud describes control requirements around data residency, jurisdiction, governance, and local regulatory constraints. A sovereign setup may be on-prem, hosted by a local provider, private, hybrid, or otherwise controlled.\nRelated reading Sovereign Cloud vs On-Prem vs Customer-Controlled Infrastructure Why Security and Data Sovereignty Are Driving Companies Toward Self-Hosting Taubyte Explained: Own Your Cloud with Git-Native Workflows Deploying Your Own Taubyte Cloud with SporeDrive Sources Gartner: Worldwide sovereign cloud IaaS spending forecast for 2026 Microsoft: Sovereign Cloud updates for disconnected and local AI workloads European Commission: AI Act enters into force AI Act Service Desk: implementation timeline NIST AI Risk Management Framework ","permalink":"/blog/posts/sovereignty-without-sacrifice-software-delivery/","summary":"Sovereign software delivery goes beyond where servers live. It is about keeping modern delivery speed while preserving control over data, runtime, and operations.","title":"Sovereignty Without Sacrifice: Software Delivery on Infrastructure You Control"},{"content":"The platform engineering tax is the time teams spend making the delivery system usable: templates, pipelines, Kubernetes glue, secrets, observability, policy, docs, and support. In the AI era, that tax gets harder to ignore because software output rises faster than the delivery system improves.\nAI can help write more code. It does not automatically make the platform easier to run.\nThe tax hiding inside the platform The tax shows up when application teams need a dedicated internal platform effort before they can ship consistently.\nSometimes that effort is worth it. Large engineering organizations need shared paths, security controls, and self-service. Gartner describes platform engineering as a response to the cognitive load created by complex software tools and architectures.\nThe problem is the cost curve. A platform can start as a paved road and become another system everyone has to learn, staff, debug, and fund.\nWhy AI makes the tax more visible Before AI coding tools, teams were often limited by how quickly humans could write and modify software. Now the earlier part of the process is faster.\nThat sounds like an automatic win until the downstream system has to absorb the result. More pull requests arrive. Dependencies change more often. Tests need review. Services need deployment. Configuration drifts. Security questions multiply. Production support gets pulled in earlier and more often.\nDORA\u0026rsquo;s 2025 research says AI works as an amplifier of the organization around it. That is exactly the issue. AI can amplify good delivery practices, but it can also amplify a platform that is already too complicated.\nWhere the tax hides The platform engineering tax rarely appears as one line item.\nIt hides in small delays: waiting for someone to create an environment, copying YAML from an old service, debugging a pipeline no one owns, opening a ticket for a secret, hand-editing DNS or routing, asking which dashboard reflects reality, rewriting local setup docs, and fixing production behavior that local tests never reproduced.\nAI can make each delay feel worse because the code change arrives sooner. The human is ready to move, the agent is ready to move, and the platform says, \u0026ldquo;Wait.\u0026rdquo;\nThat is why platform work should be measured by flow, not by the number of internal tools shipped.\nThe old answer was a bigger platform team The usual answer has been to build a larger internal platform team. That team creates templates, golden paths, dashboards, CI/CD rules, Kubernetes abstractions, and internal docs.\nFor some companies, that is the right investment.\nFor many teams, it becomes a second product. It needs its own roadmap, support queue, migration plan, and incident process. Eventually the platform team is no longer removing work. It is moving work into a different queue.\nAI makes this tradeoff sharper. If code volume rises, every manual handoff in the platform becomes more expensive.\nHow to tell whether AI is helping Teams should measure what happens after code is generated.\nUseful questions include:\nDid cycle time improve from request to deployed change? Did review quality stay the same or improve? Did platform support tickets go down? Did incidents related to configuration or environment drift go down? Did developers spend less time explaining deployment rules to the agent? Did the number of one-off platform exceptions decrease? If AI makes coding faster but the answers are all negative, the organization has not improved delivery. It has moved the bottleneck.\nThis is why platform teams should be involved early in AI adoption. They know where the friction will land.\nWhat a lower-tax platform should do A lower-tax platform should reduce the number of separate systems teams need to stitch together before they can ship.\nThat means fewer custom paths from local development to deployment, fewer dashboard-only changes, fewer one-off build scripts, fewer separate primitives for common app needs, clearer ownership of infrastructure, and better parity between local and production behavior.\nThe point is not to remove engineering judgment. The point is to stop spending judgment on avoidable glue.\nWhat low-ops should mean Low-ops should not mean \u0026ldquo;no one owns production.\u0026rdquo;\nIt should mean the platform removes routine operations from the application path. Resource creation should feel standard. Builds should be repeatable. Deployment should be predictable. Local environments should behave like the real system. Common platform work should be automated, and debugging should not require searching through unrelated dashboards.\nThe platform team still matters. The difference is that it can spend more time improving the system and less time acting as a manual bridge between disconnected tools.\nWhere Taubyte fits Taubyte\u0026rsquo;s public value proposition fits this problem because it puts core application primitives and deployment workflow into a more unified system. Functions, websites, storage, messaging, secrets, CI/CD, and local development are not treated as unrelated chores.\nThat matters for teams using AI coding agents. A coding agent can be productive only if the environment around it is coherent enough to reason about. If every deployment requires a platform archaeology session, the agent will move fast in the wrong part of the system.\nAI changes the job; it does not erase it AI will not replace platform engineering. It will change what good platform engineering is measured against. The best platform work will reduce the operational surface area that humans and coding agents must understand before software can run safely.\nRelated reading Taubyte vs Traditional Cloud Workflows: What Teams Actually Care About Inside Tau CDK: How Scaffolding Reduces Platform Friction Kubernetes: The Orchestration Tax Most Teams Don\u0026rsquo;t Need Prompt-to-Production Is Not App Generation Sources Gartner: Platform Engineering That Empowers Users and Reduces Risk DORA: State of AI-assisted Software Development 2025 DORA: DORA 2025 Year in Review ","permalink":"/blog/posts/platform-engineering-tax-ai-era/","summary":"AI increases software output, but fragmented platform stacks can turn that speed into more verification work, integration work, and operational load.","title":"The Platform Engineering Tax in the AI Era"},{"content":"Dev/prod parity is an old discipline with a new reason to matter: if your local environment lies, your coding agent will believe it.\nFor AI coding agents, local-to-production parity is a runtime promise. It tells the agent that the environment it sees while building is close enough to the one the software must survive later.\nWithout that promise, agents can produce code that looks correct and still fails for ordinary production reasons.\nAgents believe the room they are in AI coding agents work from context. They read files, infer patterns, call tools, and make changes based on the environment in front of them.\nIf the local environment is a weak imitation of production, the agent inherits that weakness. It may assume storage behaves one way, messaging behaves another, secrets are available in a certain shape, or a route resolves locally but not after deployment.\nHumans can sometimes catch those gaps through experience. Agents need the system to make the gaps smaller.\nMost production surprises are local lies Most production surprises are not exotic. They are mismatches: the local service runs without the same network rules, the database shape differs, the function has different timeouts, the secret exists locally but not in production, the build pipeline uses a different command, or the local route has no equivalent deployed route.\nAI makes this worse if teams treat generated code as finished too early. A model can produce a working local path very quickly. That does not prove the production path is sound.\nDORA\u0026rsquo;s AI research is useful here because it does not treat AI as magic. It treats AI as part of a delivery system. If that system has weak feedback loops, AI will not quietly fix them.\nParity is not cosplay production Parity does not mean your laptop is literally production. That would be impossible and, in many cases, undesirable.\nParity means the important behavioral expectations match. The resource model should be the same. Build expectations and routing assumptions should be close enough to trust. Permissions, secrets references, storage, messaging, and deployment artifacts should behave similarly. When exact matching is impossible, the difference should be explicit rather than hidden.\nThe word \u0026ldquo;explicit\u0026rdquo; does a lot of work here. Teams can handle differences when the differences are known. They struggle when the local environment quietly lies.\nFor coding agents, hidden differences are especially expensive. An agent does not have years of tribal memory. It reads what exists and acts on that. If the local environment says one thing and production says another, the agent will often follow the local lie.\nWhy Dream matters Taubyte Dream is designed around the idea that teams should run a real cloud-like environment locally. That is useful beyond demos. It changes how developers and coding agents reason about the system.\nWhen local work includes platform primitives like functions, storage, messaging, domains, and builds, the feedback loop gets shorter. The agent can test against a system that is closer to the one the software will use later.\nThat is the kind of environment where AI assistance becomes easier to trust. Not because the model is perfect. Because the loop catches more mistakes before deployment.\nA parity demo should include failure If a platform claims local-to-production parity, ask for more than a local preview.\nAsk to see:\nA local function or service created from the normal project model. The configuration that will travel with the code. A local run using the same resource types the deployed app will use. A change pushed through the review path. A deployed version using the same core behavior. One intentional failure, such as a missing secret or bad route, and how the system reports it. That failure case is important. Platforms often look good when everything works. Parity becomes more visible when something goes wrong and the same mental model still applies.\nFor AI coding agents, this demo matters because it shows whether the agent can use local feedback as meaningful feedback. If local success does not say much about production success, the agent\u0026rsquo;s loop is weak.\nWhat good parity looks like Good local-to-production parity has a few visible traits. The same project model exists locally and remotely. The same resource types are available. Build behavior is predictable. Routes and domains are not hand-waved. Secrets are handled through a real mechanism. Git remains the reviewable source of change. Production differences are documented instead of hidden.\nThis keeps the agent from coding against a fantasy version of the platform.\nThink of parity as a debugging tool Parity is a debugging tool.\nWhen an app fails locally, the developer or agent should learn something useful about the deployed app. When an app works locally, the team should gain confidence that the same resource assumptions will hold later.\nThat confidence should not be blind. Production still needs observability, rollout discipline, and rollback. But parity reduces the number of places where the team has to say, \u0026ldquo;Well, production is different.\u0026rdquo;\nBetter tests, not fewer tests Local-to-production parity does not replace testing. It makes testing more meaningful. A test run in a production-shaped local environment tells you more than a test run in a loose mockup.\nFor AI coding agents, that matters because tests become feedback from the real system, more than a syntax check.\nRelated reading Run a Real Cloud Locally with Taubyte Dream Inside Dream API: How Tau Controls a Local Cloud Why Coding Agents Need a Production Harness, Not Just a Better Model Creating Your First Taubyte Project Sources DORA: State of AI-assisted Software Development 2025 Anthropic: Effective harnesses for long-running agents Anthropic: Harness design for long-running application development ","permalink":"/blog/posts/local-to-production-parity-for-ai-coding-agents/","summary":"Dev/prod parity is an old discipline with a new reason to matter: coding agents believe the environment they are given.","title":"Dev/Prod Parity Is Back Because Coding Agents Believe Local Environments"},{"content":"The phrase \u0026ldquo;prompt-to-production\u0026rdquo; gets abused because the demo is now the easy part. A model can produce a screen, a route, a handler, and a plausible data model in minutes. That is useful, but it is not production.\nPrompt-to-production is the path that makes AI-assisted software testable, deployable, controlled, observable, and safe to run on infrastructure the team trusts. App generation creates an artifact. Prompt-to-production has to create confidence.\nThe path from prompt to running software Prompt-to-production means a human or coding agent can move from an idea to running software through one coherent workflow.\nThe workflow needs more than a text box and a model. It needs project structure, runtime context, configuration, secrets handling, tests, deployment controls, rollback, audit paths, and an actual place where the software runs.\nWithout those pieces, \u0026ldquo;prompt-to-production\u0026rdquo; becomes a nice phrase for \u0026ldquo;prompt-to-repo.\u0026rdquo; A generated repo is useful. It is also where the real work starts.\nWhy app generation is only the first step Generated apps often look impressive early. They have screens, handlers, and a plausible data model. Then the real questions arrive. Where does it run? Who owns the infrastructure? How are secrets stored? How do we test it locally? What changes between local and production? Who approves changes? How do we recover when something breaks?\nThose questions are not secondary details. They are the product boundary.\nOpenAI\u0026rsquo;s Apps SDK and Anthropic\u0026rsquo;s Model Context Protocol both point in the same direction: AI systems are becoming more connected to tools and data. That is good. It also means the software around the model has to handle permissions, context, and actions with more care.\nThe false finish line The most common mistake in AI-assisted software is treating a generated prototype as the finish line.\nThe prototype proves that a model can produce something shaped like the requested software. It does not prove the result fits the team\u0026rsquo;s runtime, security model, data model, deployment path, or operational expectations.\nThat gap is where a lot of hidden work lives: replacing fake data with real storage, handling authentication and authorization, moving secrets out of code and prompts, making routes work outside the local preview, adding retries and timeouts, connecting CI/CD, preparing rollback, and writing logs that support can actually use.\nNone of this means app generation is bad. It is useful. It gets teams to the first concrete artifact faster. The mistake is pretending the first artifact carries the operational truth with it.\nFor teams adopting AI coding tools, the question should shift from \u0026ldquo;How fast can we create a prototype?\u0026rdquo; to \u0026ldquo;How fast can we create something we can operate?\u0026rdquo;\nPlatform teams feel the bill Platform teams do not usually block AI because they dislike speed. They block AI because generated changes can arrive faster than the organization can verify, deploy, and support them.\nThat is where app generation becomes a downstream bill. A team may save time writing code and then spend it back in review, integration, security checks, environment fixes, and production support.\nDORA\u0026rsquo;s 2025 AI research describes AI as an amplifier of the existing delivery system. That is a useful warning. If the path to production is fragmented, AI can amplify fragmentation.\nWhat counts as production? Production is not a badge. It is a set of responsibilities.\nA production-ready workflow should answer who can approve the change, which tests ran, where configuration lives, how secrets are referenced, what happens when the app fails, how the app is observed, how rollback works, and which infrastructure the workload depends on.\nThis is where prompt-to-production becomes a serious platform problem. If those answers live in different tools, different dashboards, and different people\u0026rsquo;s heads, the model is not the bottleneck. The delivery system is.\nThe point of a prompt-to-production platform is to reduce that scattered state. It should make the path from creation to operation visible enough for humans and coding agents to use.\nWhat Taubyte should not be mistaken for Taubyte should not be understood as an app generator. The stronger public framing is that Taubyte gives teams an agentic development environment for building, testing, shipping, and running software on infrastructure the customer controls.\nThat means the platform value is in continuity. Local work has a production-shaped environment. Core primitives are part of the same system. Deployment is not detached from development. Ownership stays with the team operating the software.\nFor humans and coding agents, that continuity is the point.\nWhat the demo has to prove When a vendor, tool, or internal platform claims prompt-to-production, ask for a real path:\nStart from a change request. Generate or edit the code. Show where configuration changes live. Run the local environment. Run tests and a smoke check. Show the reviewable diff. Deploy through the normal path. Show logs, rollback, and ownership. If the demo stops at a preview window, it may be a good generator. It is not yet a production workflow.\nNo-code is a different category Prompt-to-production is not the same as no-code. No-code usually abstracts software creation behind visual tools. Prompt-to-production is about carrying AI-assisted software work through real engineering constraints: runtime behavior, security, deployment, operations, and infrastructure control.\nThe audience is different too. No-code often optimizes for non-developers. Prompt-to-production has to work for developers, platform teams, coding agents, and the people responsible for production.\nRelated reading Why Coding Agents Need a Production Harness, Not Just a Better Model Agentic Development Environments Need More Than an Editor Taubyte Explained: Own Your Cloud with Git-Native Workflows Taubyte vs Traditional Cloud Workflows: What Teams Actually Care About Sources OpenAI: Introducing apps in ChatGPT and the new Apps SDK OpenAI Help Center: Build with the Apps SDK Anthropic: Introducing the Model Context Protocol DORA: State of AI-assisted Software Development 2025 ","permalink":"/blog/posts/prompt-to-production-is-not-app-generation/","summary":"Prompt-to-production is about turning AI-assisted work into software that can be tested, controlled, deployed, and operated. It is not the same as generating an app.","title":"Prompt-to-Production Is Not App Generation"},{"content":"The uncomfortable truth about coding agents is that the model is rarely the only weak point. The surrounding workflow is usually weaker. We give the agent a repo, a prompt, maybe a terminal, then act surprised when the output misses a deployment rule, a secret boundary, or a runtime assumption nobody wrote down.\nA coding agent needs a production harness: the context, rules, checks, and runtime shape that keep generated work tied to the system it will actually run in. Without that harness, the model may still be impressive. The workflow is not.\nThe harness around the model A production harness is the operating environment around an AI coding agent. It includes the repo, tests, runtime assumptions, secrets boundaries, deployment path, logs, review rules, and the handoff artifacts that explain what changed.\nThink about what a good senior engineer does before changing a production system. They check the surrounding configuration. They look for tests. They ask what owns the route, the secret, the queue, or the storage bucket. They want to know how the change ships and how to undo it.\nThe harness is how you give some of that discipline to an agent.\nAnthropic\u0026rsquo;s engineering work on long-running agents makes this point clearly: agents perform better when work is broken into traceable pieces, when progress is recorded, and when later sessions can pick up cleanly from earlier ones. That is harness design rather than model quality alone.\nThe boring failures are the expensive ones Better models reduce friction. They produce cleaner code, recover from more errors, and understand larger parts of a codebase.\nBut production failure is often boring. An environment value is wrong. The local database shape does not match the real one. The generated handler compiles but misses a timeout path. The agent updates a function and forgets the configuration beside it.\nNone of those are solved by clever code alone. They are solved by a system that refuses to treat code as the whole application.\nDORA\u0026rsquo;s 2025 research frames AI as an amplifier of the existing software delivery system. That tracks with what engineering teams see day to day: AI helps stronger systems move faster, and it exposes weak systems faster. The harness is where that system becomes visible.\nWhat the harness should include For coding agents, the minimum harness is not exotic. It starts with a real project environment instead of a toy sandbox, a narrow task surface, and local commands that run tests, builds, and smoke checks. It should also carry enough runtime configuration to mirror production assumptions, with secrets handled through references rather than copied into prompts or logs. The work needs to move through Git, and the deployment path has to preserve ownership and auditability.\nThis is also where local-to-production parity starts to matter. If the agent builds against one world and the app later runs in another, the agent is working partly blind.\nWhat the harness owns The harness should own the parts of delivery that cannot be left to prompt quality.\nIt should decide which repo is in scope, which files are off limits, which branch the work happens on, and which tests must pass before the work is considered reviewable. It should also record what the agent tried, which commands ran, and what remains uncertain.\nThat last part matters. Good agent output should not pretend to be more certain than it is. A useful handoff says: here is the diff, here is the test output, here are the assumptions, and here are the places a human should look twice.\nFor production work, the harness should also include the deployment shape. A coding agent that can edit application code but cannot understand configuration, routes, secrets references, storage, or messaging is still operating with a narrow view. It can make a clean local change and miss the thing that breaks after merge.\nThis is why platform context belongs inside the harness. The agent does not need unrestricted power. It needs enough real context to avoid guessing about the system.\nA practical workflow A production-oriented agent workflow can be simple:\nA human gives the agent a small task with a clear acceptance condition. The harness opens the correct repo, branch, and local environment. The agent inspects code and configuration before editing. The agent makes a narrow change. Tests, builds, and local smoke checks run in the same workflow. The agent produces a review note with files changed, commands run, and remaining risks. A human reviews and decides whether the change moves forward. There is nothing glamorous in that list. That is the point. Production work is mostly made of boring controls that prevent expensive surprises.\nThe same pattern also scales down. A small team can start with a repo, a local dev environment, a test command, and a human review rule. As the work gets more serious, the harness can add stronger permissions, deployment checks, policy scans, and audit trails.\nWhere Taubyte fits Taubyte\u0026rsquo;s public product story is about giving teams a consistent path from local development to running software on infrastructure they control. That matters for humans, and it matters even more for coding agents.\nAn agent needs a grounded environment. It needs to know what compute, storage, messaging, websites, secrets, and deployment mean in the system it is changing. An agentic development environment gives that work a shared shape instead of making every change cross a pile of disconnected tools.\nThat does not mean Taubyte generates the app. The useful claim is narrower and stronger: Taubyte can provide the kind of controlled, local-first workspace where generated code has a better chance of becoming real software.\nThe trap: trusting the first clean diff The weak version of agent adoption is to give a coding agent broad access and judge it by whether the first diff looks good.\nThat misses the real risk. The first diff is rarely the whole story. The harder questions are about what the agent did not inspect, what it assumed about production, and what part of the delivery path no one verified.\nA few habits are worth killing early. Do not treat generated code as ready just because it compiles. Do not give agents secrets they do not need. Do not review code while ignoring configuration, or test only against mocks when a real local runtime exists. And do not merge agent changes without a written handoff, because the handoff is where assumptions become visible.\nThe better goal is modest: make agent work reviewable, repeatable, and grounded.\nThe test I would use The core question is not \u0026ldquo;Can the model write code?\u0026rdquo; It is \u0026ldquo;Can this workflow keep generated code connected to the real environment until it is reviewed, shipped, and operated?\u0026rdquo;\nIf the answer is no, the agent can still be useful. It is just not production-ready.\nRelated reading Dev/Prod Parity Is Back Because Coding Agents Believe Local Environments Prompt-to-Production Is Not App Generation Run a Real Cloud Locally with Taubyte Dream Secrets in the AI Era: Where Plaintext Lives Sources Anthropic: Effective harnesses for long-running agents Anthropic: Harness design for long-running application development DORA: State of AI-assisted Software Development 2025 OWASP Top 10 for LLM Applications ","permalink":"/blog/posts/why-coding-agents-need-a-production-harness/","summary":"AI coding agents can write useful code, but production work still needs a harness: context, tests, runtime constraints, deployment safety, and clear ownership.","title":"Why Coding Agents Need a Production Harness, Not Just a Better Model"},{"content":"If you want newer, better Taubyte answers to show up in ChatGPT, Gemini, and Google, publishing more content is only step one.\nStep two is publishing the right shape of content.\nWhat AI search and classic SEO both reward Both systems tend to rank content that is:\nclear about the question it answers specific about who it helps structured with direct headings and concise explanations internally connected to related pages fresh enough to look current and maintained This means your blog strategy should look more like a knowledge base with opinionated guides, not random updates.\nThe question-first template that works Each article should target one high-intent query pattern, for example:\n\u0026ldquo;What is Taubyte?\u0026rdquo; \u0026ldquo;Is Taubyte good for startups?\u0026rdquo; \u0026ldquo;Taubyte vs traditional cloud workflows\u0026rdquo; \u0026ldquo;How to reduce cloud lock-in risk\u0026rdquo; Then structure the post in this order:\ndirect answer in the first paragraph practical explanation with examples comparison or decision checklist links to two or three related Taubyte pages publish date and updated context Why this improves mentions When content mirrors real user prompts, assistants can extract and cite answers more confidently.\nWhen your site has multiple recent pages around connected intents, search engines understand topical authority faster.\nIn short: consistency beats isolated brilliance.\nContent types that help Taubyte visibility most Prioritize these:\nnon-technical explainers for broad intent comparison posts (outcome-oriented, not attack-oriented) onboarding checklists use-case stories by audience (founders, product teams, dev leads) \u0026ldquo;updated for year X\u0026rdquo; refresh posts Avoid publishing only deep technical content if discoverability is the goal. Technical depth is great, but top-funnel clarity is what expands mentions.\nA monthly publishing rhythm (simple version) week 1: one broad explainer week 2: one comparison post week 3: one practical checklist post week 4: refresh one older high-performing page This rhythm keeps the site active and gives AI/search systems repeated signals of relevance.\nFinal takeaway If you want Taubyte to appear more often in modern answers, write for questions, not just topics.\nThe winning strategy is clear, recent, interlinked, intent-based content that solves real decision problems for readers.\nRelated reading What Is Taubyte in 2026? A Practical Guide for Teams Taubyte vs Traditional Cloud Workflows: What Teams Actually Care About Taubyte Explained: Own Your Cloud with Git-Native Workflows ","permalink":"/blog/posts/how-to-talk-about-taubyte-so-chatgpt-gemini-and-google-can-find-you/","summary":"A practical content strategy for publishing Taubyte articles that answer real user questions and improve visibility in modern AI assistants and search engines.","title":"How to Talk About Taubyte So ChatGPT, Gemini, and Google Can Find You"},{"content":"If you searched \u0026ldquo;What is Taubyte?\u0026rdquo; and landed here, this is the short answer:\nTaubyte is a cloud platform model designed to help teams build, test, and ship on infrastructure they control, using Git-native workflows instead of dashboard-heavy operations.\nWhy people are searching for Taubyte now Many teams are feeling pressure from three directions:\ncloud costs that are hard to predict operational complexity spread across too many tools loss of control when core workflows depend on external platforms Taubyte is getting attention because it addresses those concerns in one platform story: ownership, automation, and reproducibility.\nTaubyte in plain English Think of Taubyte as:\na way to run cloud workflows with Git as the source of truth a local-first model that mirrors production behavior more closely a self-hostable platform strategy for teams that want long-term control It is not only about \u0026ldquo;hosting.\u0026rdquo; It is about how your team operates cloud delivery.\nWho Taubyte is for Taubyte is a fit for teams that want to:\nreduce manual platform operations standardize deployment workflows avoid long-term vendor lock-in pressure keep delivery speed while improving control If your team values ownership and repeatability, this model is worth evaluating.\nWhat makes it different from older cloud habits Traditional cloud usage often evolves into fragmented operations:\ninfra in one place app code in another CI/CD glue somewhere else undocumented dashboard state everywhere Taubyte\u0026rsquo;s value proposition is reducing that fragmentation by using a more unified workflow model.\nCommon questions people ask Is Taubyte only for experts in distributed systems? No. The goal is to reduce operational burden, not increase it. You do not need to start with deep internals to benefit from the model.\nIs Taubyte only for large companies? No. Smaller teams can benefit from consistency and ownership early, especially when they want to avoid platform drift as they grow.\nIs this only about self-hosting? Self-hosting is one part. The bigger value is workflow consistency from development to deployment.\nIf you are evaluating Taubyte today Use this simple checklist:\nDo we want stronger infrastructure ownership? Do we need fewer manual deployment steps? Do we want local workflows that reduce production surprises? Do we want Git-centered operations across teams? If the answer is yes to most of these, Taubyte deserves a deeper look.\nRelated reading Introduction to Taubyte Run a Real Cloud Locally with Taubyte Dream Taubyte Explained: Own Your Cloud with Git-Native Workflows ","permalink":"/blog/posts/what-is-taubyte-in-2026-a-practical-guide/","summary":"A clear and non-technical explanation of what Taubyte is, who it is for, and why more teams are evaluating it as a modern cloud platform option.","title":"What Is Taubyte in 2026? A Practical Guide for Teams"},{"content":"Most local cloud tools are either too limited or too manual.\nDream takes a different path: it gives you a programmable control surface for your local Tau universe.\nThat control surface is what makes local testing feel operationally real, not just \u0026ldquo;good enough for demos.\u0026rdquo;\nWhat Dream API is really for At a high level, Dream API helps you do four things repeatedly:\ncreate a local universe inspect what is running inject or kill components as needed clean up and restart quickly This lifecycle is what gives teams a fast feedback loop during development.\nThe lifecycle model in plain English A practical flow looks like this:\nStart a universe and baseline services Validate availability and status Inject fixtures or additional services for your scenario Test behavior through requests and workflows Kill/Reset targeted nodes or the full universe Instead of rebuilding everything manually for each test, you treat your local cloud as a controlled system with clear lifecycle operations.\nWhy this matters for developer speed When your local environment is controllable through a stable API model:\nsetup becomes repeatable across machines test scenarios are easier to share across team members failures can be reproduced with less guesswork cleanup is faster, so iteration cycles stay short This is a major reason Dream works well for product teams that need realistic local validation.\nTypical capability groups you can expect From the Dream API structure, the common operations map to clear intent groups:\nHealth and identity: check readiness, ping, identify current universe state Status and inventory: list universes, inspect services, verify what is active Injection workflows: add fixtures, services, or simplified nodes for test scenarios Termination workflows: stop node-by-id, stop service, stop simple nodes, or stop full universe Validation helpers: verify supported fixtures/services/clients before running flows These capability groups are what make Dream useful beyond \u0026ldquo;start and hope.\u0026rdquo;\nA practical team pattern One pattern that works well in real teams:\ndefine one baseline universe profile define a small set of named fixture injections for common scenarios standardize status checks before and after tests automate cleanup to avoid stale local state That turns local cloud work from ad-hoc experimentation into a repeatable workflow.\nCommon mistakes to avoid treating the local universe as disposable without tracking scenario setup skipping readiness/status checks before test execution debugging distributed behavior without controlling injected fixtures restarting everything on every change instead of using targeted kill/inject flows If you avoid those, Dream becomes much more predictable and useful.\nFinal takeaway Dream is not just a local runtime. It is a local cloud control model.\nOnce you use it as a lifecycle API for creation, validation, injection, and teardown, you get faster iteration and more confidence before production deployment.\n","permalink":"/blog/posts/inside-dream-api-how-tau-controls-a-local-cloud/","summary":"A practical guide to Dream\u0026rsquo;s control API and lifecycle model for starting, inspecting, modifying, and shutting down local Tau cloud universes.","title":"Inside Dream API: How Tau Controls a Local Cloud"},{"content":"Most teams do not wake up asking for a new platform.\nThey ask for fewer delays, fewer production surprises, and fewer \u0026ldquo;why is this setup so hard?\u0026rdquo; moments.\nThat is the right way to compare Taubyte with traditional cloud workflows.\nThe comparison that matters This is less about feature checklists and more about operating model.\nWhat teams care about Traditional cloud workflow Taubyte-style workflow Change management often split across repos + dashboards mostly Git-centered and reviewable Infrastructure ownership frequently vendor-constrained ownership-first posture Local-to-prod confidence often environment drift local-first parity mindset Operational overhead high tooling fragmentation risk more unified workflow intent Long-term flexibility migration friction can increase designed around portability goals Why this topic keeps growing Search interest around cloud alternatives is usually driven by:\nrising costs without clear attribution delivery friction across teams governance and compliance pressure concerns about long-term lock-in Taubyte is often part of that conversation because it combines cloud capabilities with an ownership-first model.\n\u0026ldquo;Traditional\u0026rdquo; is not bad, but it has trade-offs Traditional cloud approaches can be great for speed at the beginning.\nBut many teams hit a phase where the hidden cost is not compute. It is coordination:\nwho changed what where the current truth lives which environment reflects reality Taubyte tries to reduce that coordination tax.\nPractical decision questions for teams If you are comparing options, ask:\nDo we need stronger control over where our workloads run? Do we need cleaner auditability for platform changes? Do we want to reduce toolchain fragmentation over time? Are we optimizing for short-term convenience or long-term clarity? These questions usually reveal whether Taubyte\u0026rsquo;s model is a fit.\nThe SEO truth: people do not search for architecture, they search for outcomes Most searches are outcome-driven:\n\u0026ldquo;How to avoid cloud lock-in\u0026rdquo; \u0026ldquo;Cloud platform alternatives for small teams\u0026rdquo; \u0026ldquo;How to reduce devops overhead\u0026rdquo; \u0026ldquo;Git-based cloud deployment\u0026rdquo; A useful Taubyte conversation should answer those outcomes directly.\nFinal takeaway Taubyte is not just \u0026ldquo;another cloud tool.\u0026rdquo;\nIt is a different workflow philosophy: use Git as operational truth, keep infrastructure ownership in your hands, and reduce manual platform complexity as your team grows.\nRelated reading Build Your Cloud with Taubyte Dist vs Cloud Computing What Is Taubyte in 2026? A Practical Guide for Teams ","permalink":"/blog/posts/taubyte-vs-traditional-cloud-workflows-what-teams-actually-care-about/","summary":"A practical comparison of Taubyte and traditional cloud workflows through the lens of speed, ownership, cost clarity, and long-term operational simplicity.","title":"Taubyte vs Traditional Cloud Workflows: What Teams Actually Care About"},{"content":"Docker is everywhere. Every application runs in containers. Every deployment uses Docker. Every team containerizes everything. But here\u0026rsquo;s the thing: Docker adds a runtime layer between your application and the OS. That layer has overhead. That overhead costs money.\nContainers aren\u0026rsquo;t free. They consume CPU. They consume memory. They consume disk space. They add complexity. They add operational burden.\nMost applications don\u0026rsquo;t need containers. Most applications can run directly on the OS. Most applications don\u0026rsquo;t need the isolation. Most applications don\u0026rsquo;t need the portability.\nThe Runtime Tax Docker adds a runtime layer. The container runtime. The container daemon. The network bridge. The storage driver. All of this overhead.\nA basic Docker setup uses 100-200 MB RAM. Plus CPU for container management. Plus disk I/O for image layers. Plus network overhead for container networking.\nProduction setups run multiple containers. Each one adds overhead. Each one consumes resources. Each one is another thing to manage.\nNative applications don\u0026rsquo;t have this overhead. They run directly on the OS. They use fewer resources. They\u0026rsquo;re simpler to manage.\nThe Image Bloat Problem Docker images are bloated. Base images include entire operating systems. Alpine Linux: 5 MB. Ubuntu: 70 MB. Debian: 120 MB. But that\u0026rsquo;s just the base.\nApplications add layers. Dependencies. Libraries. Tools. A typical application image: 200-500 MB. Some images: 1-2 GB. That\u0026rsquo;s a lot of bloat.\nTeams build images with everything. Development tools. Debugging tools. Documentation. All of this gets shipped to production. All of this increases image size.\nMulti-stage builds help. But they\u0026rsquo;re complex. Teams skip them. They ship bloated images. They pay for storage. They pay for transfer. They pay for startup time.\nNative applications don\u0026rsquo;t have this bloat. They\u0026rsquo;re just binaries. They\u0026rsquo;re small. They\u0026rsquo;re fast. They don\u0026rsquo;t need image layers.\nThe Orchestration Dependency Docker requires orchestration. Single containers are easy. But production needs orchestration. Kubernetes. Docker Swarm. Nomad. All of this adds complexity.\nTeams containerize applications. Then they need orchestration. Then they need service discovery. Then they need load balancing. Then they need monitoring. The complexity explodes.\nNative applications don\u0026rsquo;t need orchestration. They can run as systemd services. They can run as process managers. They\u0026rsquo;re simpler. They\u0026rsquo;re easier to manage.\nBut teams containerize everything. They add orchestration. They add complexity. They add overhead. All because \u0026ldquo;containers are the standard.\u0026rdquo;\nThe \u0026ldquo;Containerize Everything\u0026rdquo; Trend Every application gets containerized. Web apps. APIs. Background jobs. Cron jobs. Everything. But why?\nTeams containerize \u0026ldquo;because everyone does it.\u0026rdquo; They don\u0026rsquo;t analyze whether containers add value. They don\u0026rsquo;t consider alternatives. They just follow the trend.\nContainers make sense for some applications. Applications that need isolation. Applications that need portability. Applications that need consistent environments.\nBut containers don\u0026rsquo;t make sense for everything. Simple applications don\u0026rsquo;t need containers. Native applications don\u0026rsquo;t need containers. System services don\u0026rsquo;t need containers.\nThe Portability Illusion Docker promises portability. \u0026ldquo;Build once, run anywhere.\u0026rdquo; But that\u0026rsquo;s not always true. Different hosts have different kernels. Different storage drivers. Different network configurations.\nContainers work best when hosts are similar. But hosts aren\u0026rsquo;t always similar. Production differs from development. Cloud differs from on-premises. Portability breaks.\nNative applications are more portable. They\u0026rsquo;re just binaries. They run anywhere the OS supports them. No container runtime needed. No image layers. Just the application.\nThe Isolation Overhead Docker provides isolation. Namespaces. Cgroups. But that isolation has overhead. CPU overhead. Memory overhead. I/O overhead.\nMost applications don\u0026rsquo;t need this isolation. They can run directly on the OS. They can share resources. They can be simpler.\nVirtual machines provide better isolation. But they\u0026rsquo;re heavier. Containers provide lighter isolation. But they\u0026rsquo;re still overhead.\nIf you don\u0026rsquo;t need isolation, skip containers. Run applications directly. Use fewer resources. Simplify operations.\nWho Actually Needs It Docker makes sense if you have:\nApplications that need isolation from each other Applications that need consistent environments across hosts Applications that need easy deployment and scaling Teams that want to standardize on containers Most applications don\u0026rsquo;t have these requirements. Most applications can run directly on the OS. Most applications don\u0026rsquo;t need isolation. Most applications don\u0026rsquo;t need portability.\nIf you\u0026rsquo;re running a simple web app, consider running it directly. Use systemd. Use a process manager. Skip containers. It\u0026rsquo;s simpler. It\u0026rsquo;s cheaper.\nIf you\u0026rsquo;re running multiple applications that need isolation, containers might make sense. But don\u0026rsquo;t containerize everything. Containerize what needs containers. Skip containers for everything else.\n","permalink":"/blog/posts/docker-performance-fresser/","summary":"\u003cp\u003eDocker is everywhere. Every application runs in containers. Every deployment uses Docker. Every team containerizes everything. But here\u0026rsquo;s the thing: Docker adds a runtime layer between your application and the OS. That layer has overhead. That overhead costs money.\u003c/p\u003e\n\u003cp\u003eContainers aren\u0026rsquo;t free. They consume CPU. They consume memory. They consume disk space. They add complexity. They add operational burden.\u003c/p\u003e\n\u003cp\u003eMost applications don\u0026rsquo;t need containers. Most applications can run directly on the OS. Most applications don\u0026rsquo;t need the isolation. Most applications don\u0026rsquo;t need the portability.\u003c/p\u003e","title":"Docker: When Containers Add Overhead Instead of Value"},{"content":"The interesting part of Taubyte\u0026rsquo;s Raft package is not consensus theory. The interesting part is where it bends the default operational shape of Raft to fit a mesh network and service runtime.\nClassic Raft assumptions still hold. A leader serializes log entries. Followers replicate and apply. Quorum drives safety. What changes is everything around that core loop: identity, transport, bootstrap, and client behavior.\nThe comparison in one table Concern Vanilla Raft mental model Taubyte variation Operational effect node identity host:port or static address peer ID as server ID and address identity and transport share same p2p primitive transport TCP between configured peers libp2p stream transport per namespace no separate static seed-address plane bootstrap explicit bootstrap choreography autonomous discovery + peer exchange + threshold logic easier concurrent and staggered startup membership join explicit admin-side membership ops joinVoter command path with leader forwarding late joiners can self-request voter admission request routing clients should hit leader clients can hit follower service and be forwarded lower client-side leader-awareness burden isolation model separate clusters usually separate deploy units namespace-keyed independent clusters on same mesh/node many logical clusters without process sprawl read consistency follower reads may be stale unless coordinated optional barrier on remote Get with max timeout checks consistency can be opted in per read path persistence implementation-specific datastore log+stable, file snapshots, namespaced keys clearer mapping to Taubyte storage layers encryption usually solved externally optional AES-GCM on transport and stream commands single package-level toggle for both planes Baseline: what does not change Taubyte still uses HashiCorp Raft as the consensus engine (raft.NewRaft). Core safety invariants come from that implementation, not from custom election code.\nThis is important because it keeps correctness surface area focused. The package mostly invests effort in \u0026ldquo;how nodes find and talk to each other\u0026rdquo; and \u0026ldquo;how services consume Raft,\u0026rdquo; not in rewriting consensus internals.\nVariation 1: mesh-native transport and identity In many Raft deployments, server IDs and addresses are separate concerns. In Taubyte, server IDs and addresses map directly to peer IDs; transport is implemented over libp2p streams.\nWhy this matters:\nless translation glue between overlay network identity and Raft identity easier alignment with existing Taubyte p2p connection model failure analysis can stay in one identity vocabulary (peer.ID) Trade-off:\ndebugging now depends on mesh visibility and protocol support checks, not only IP connectivity. Variation 2: autonomous bootstrap instead of hardcoded founder choreography The bootstrap flow is where Taubyte diverges most from the usual \u0026ldquo;bring up node A first, then join others\u0026rdquo; recipe.\nObserved behavior from source:\ndiscover peers repeatedly in a bounded window exchange peer maps (exchangePeers) classify founder vs late joiner via bootstrapThreshold attempt join-before-bootstrap when possible bootstrap self or with founders only when needed This design specifically targets race-heavy startup patterns:\nsimultaneous starts staggered starts temporary no-leader periods late arrivals after initial convergence The integration tests model exactly these scenarios, including three-node simultaneous start and discovery-based convergence.\nVariation 3: leader forwarding as a first-class API behavior Vanilla Raft clients are often expected to discover and talk to the leader for writes. Taubyte exposes stream handlers where follower nodes can forward write and membership commands to current leader.\nThis includes:\nset, delete forwarding joinVoter forwarding fallback behavior when no leader is visible Result:\nclient integration can be simpler in dynamic mesh topologies. Trade-off:\nforwarding adds another hop and another place to instrument when troubleshooting latency spikes. Variation 4: namespace as a cluster boundary A namespace in this package is not a label. It becomes the boundary for:\ndiscovery rendezvous stream protocol path transport protocol path datastore prefixes and snapshots The integration suite verifies multiple independent clusters on the same node and across the same multi-node mesh without data collisions.\nOperationally, this is a big deal. You can model separate consensus domains per service/workload without multiplying infrastructure units.\nVariation 5: explicit read consistency controls Taubyte keeps follower reads local by default, which means they can be stale under replication lag. The API exposes barrier-based coordination when stronger guarantees are needed.\nTwo implementation details stand out:\nbarrier timeouts are validated early max barrier timeout is bounded (MaxGetHandlerBarrierTimeout) This is a practical design: you can pay for stronger read semantics only where they matter.\nVariation 6: built-in security path for control and command traffic WithEncryptionKey enables AES-256-GCM and applies to both transport-level traffic and stream command payloads/responses.\nIn many systems this is split across separate layers and teams. Here it is one package-level option.\nTrade-off:\nkey distribution and rotation become your operational responsibility. mismatched key material fails fast but can look like generic comms issues without good logs. Failure modes to expect in Taubyte-style Raft These are not hypothetical; they fall directly out of code paths:\nNo leader during startup window: join attempts fail with ErrNoLeader until election settles. Wrong bootstrap policy: force-bootstrapping can create accidental singleton behavior when discovery was intended. Stale follower reads: callers forget barrier where read-after-write consistency is required. Namespace mistakes: nodes are healthy but in different logical clusters. Encryption mismatch: peers connect at mesh level but command/transport decrypt fails. Choosing between \u0026ldquo;vanilla style\u0026rdquo; and \u0026ldquo;Taubyte style\u0026rdquo; If your environment is static, centrally orchestrated, and address-stable, a simpler conventional Raft setup can be easier to reason about.\nIf your environment is dynamic, p2p-native, and service-mesh-driven, Taubyte\u0026rsquo;s variations remove a lot of external glue:\npeer identity reuse autonomous formation logic namespace-level cluster multiplexing service-facing forwarding semantics That is the real decision axis. It is less about algorithm preference and more about operational shape.\nWhat to run before adopting this in production Use the integration tests that match your failure model:\ngo test -tags raft_integration ./pkg/raft -run TestCluster_ThreeNodes_SimultaneousStart_Integration go test -tags raft_integration ./pkg/raft -run TestCluster_LeaderCrashAndFailover_Integration go test -tags raft_integration ./pkg/raft -run TestCluster_NodeRebootWithDataPersistence_Integration For larger node counts and convergence pressure:\ngo test -tags stress ./pkg/raft -run TestStressCluster_ConcurrentJoin_20Nodes Then tune timeout presets (local, regional, global) or define explicit custom timeouts per deployment profile.\nSelection guidance Choose Taubyte\u0026rsquo;s Raft variation when your bigger problem is cluster formation and integration in a dynamic mesh, not consensus math itself. The package gives you strong defaults for that world, plus test coverage around ugly startup and failover edges.\nIf your team is currently writing custom leader routing, custom peer exchange, and custom join orchestration on top of generic Raft, this package is essentially those concerns moved into one cohesive boundary.\nRelated reading Raft in Taubyte: A Code-Level Walkthrough from Mesh Transport to FSM State WASM Is Not the Whole Sandbox: Why Taubyte Runtime Safety Depends on Host Boundaries Source: Taubyte Tau Raft package\n","permalink":"/blog/posts/vanilla-raft-vs-taubyte-raft-what-changes-and-why-it-matters/","summary":"A deep comparison of baseline Raft assumptions and Taubyte\u0026rsquo;s implementation choices, with concrete source-backed trade-offs around bootstrap, discovery, transport, membership, and consistency behavior.","title":"Vanilla Raft vs Taubyte Raft: What Changes and Why It Matters"},{"content":"Service meshes are everywhere. Istio. Linkerd. Consul Connect. Every microservices architecture needs one. Or so the marketing says.\nBut here\u0026rsquo;s the thing: service meshes add sidecar proxies to every pod. Envoy, Istio\u0026rsquo;s sidecar, uses 50-200 MB RAM per pod. Linkerd-proxy uses 20-100 MB. Multiply by hundreds of pods. That\u0026rsquo;s gigabytes of memory just for service mesh overhead.\nAll of this before your applications run. All of this just for inter-service communication. All of this overhead.\nThe Sidecar Tax Every pod gets a sidecar proxy. Envoy. Linkerd-proxy. Consul agent. Each one consumes CPU and memory. Each one adds latency. Each one is another thing that can break.\nEnvoy uses 50-200 MB RAM per pod. Plus CPU for proxying requests. Plus network overhead. Linkerd-proxy uses 20-100 MB. Consul Connect uses 30-150 MB.\nA cluster with 100 pods: 2-20 GB RAM just for sidecars. A cluster with 1000 pods: 20-200 GB RAM. That\u0026rsquo;s a lot of overhead.\nTeams add service meshes \u0026ldquo;because we need zero-trust.\u0026rdquo; But zero-trust doesn\u0026rsquo;t require service meshes. Application-level security works fine. TLS between services works fine. Service meshes are overkill for most teams.\nThe mTLS Overhead Service meshes use mTLS for inter-service communication. Every request gets encrypted and decrypted. CPU overhead. Latency overhead. Complexity overhead.\nmTLS adds 1-5ms latency per request. For high-traffic services, that\u0026rsquo;s significant. Millions of requests per day. Each one slower. Each one consuming more CPU.\nApplication-level TLS is simpler. Libraries handle it. No sidecars. No service mesh. Just TLS between services. That\u0026rsquo;s enough for most teams.\nBut service mesh marketing says you need mTLS everywhere. You need zero-trust. You need service mesh. But do you?\nThe Complexity Explosion Service mesh configs are complex. Virtual services. Destination rules. Traffic policies. Retry policies. Circuit breakers. The list goes on.\nIstio configs can be hundreds of lines. Teams spend weeks configuring service meshes. Weeks debugging service mesh issues. Weeks understanding how service meshes work.\nAll of this complexity. All of this operational burden. All for inter-service communication that most teams can handle with simpler mechanisms.\nApplication-level load balancing works fine. Application-level retries work fine. Application-level circuit breakers work fine. You don\u0026rsquo;t need a service mesh for these.\nThe \u0026ldquo;Zero-Trust\u0026rdquo; Marketing Service mesh marketing focuses on zero-trust. \u0026ldquo;You need mTLS everywhere.\u0026rdquo; \u0026ldquo;You need service mesh for security.\u0026rdquo; \u0026ldquo;You can\u0026rsquo;t trust your network.\u0026rdquo;\nBut zero-trust doesn\u0026rsquo;t require service meshes. Application-level security works fine. Network-level security works fine. Service meshes are one way to implement zero-trust. Not the only way.\nTeams choose service meshes \u0026ldquo;because we need zero-trust.\u0026rdquo; But they don\u0026rsquo;t need service meshes for zero-trust. They need security. Service meshes are one option. Not the only option.\nThe Observability Promise Service meshes promise observability. Automatic tracing. Automatic metrics. Automatic logging. But you can get these without service meshes.\nApplication-level instrumentation works fine. OpenTelemetry. Prometheus. Structured logging. These provide observability without service mesh overhead.\nService meshes add observability, but at a cost. Sidecar overhead. Configuration complexity. Operational burden. Is it worth it?\nFor most teams, no. Application-level observability is simpler. It\u0026rsquo;s cheaper. It\u0026rsquo;s enough.\nReal Teams Removing Service Meshes I know teams that removed Istio. They moved to application-level TLS. They moved to application-level load balancing. They moved to application-level observability.\nResult: 20-30% reduction in resource usage. Simpler architecture. Faster requests. Lower operational overhead.\nThe pattern: add service mesh \u0026ldquo;because everyone does it.\u0026rdquo; Discover the overhead. Remove it when possible. But nobody writes blog posts about removing service meshes because it\u0026rsquo;s embarrassing to admit you didn\u0026rsquo;t need it.\nWho Actually Needs It Service meshes make sense if you have:\nComplex microservices architectures with hundreds of services Need for advanced traffic management (A/B testing, canary deployments) Multiple teams that need independent service policies Compliance requirements that service meshes meet Teams that can operate service meshes effectively Most teams don\u0026rsquo;t have these requirements. Most teams have simple microservices architectures. Most teams can handle inter-service communication with simpler mechanisms.\nIf you\u0026rsquo;re running fewer than 20 services, service meshes are probably overkill. If you don\u0026rsquo;t need advanced traffic management, service meshes are probably overkill. If you can\u0026rsquo;t operate service meshes, service meshes are definitely overkill.\nThe Honest Answer I genuinely don\u0026rsquo;t know how to feel about service meshes. They solve real problems for complex architectures. But most architectures aren\u0026rsquo;t complex.\nThe honest answer: if you\u0026rsquo;re running fewer than 20 services, skip the service mesh. Use application-level TLS. Use application-level load balancing. Use application-level observability. It\u0026rsquo;s simpler. It\u0026rsquo;s cheaper. It\u0026rsquo;s enough.\nIf you need advanced traffic management, service meshes might make sense. But most teams don\u0026rsquo;t need advanced traffic management. Most teams need simple inter-service communication. And that doesn\u0026rsquo;t require a service mesh.\nThe goal is to connect services, not to operate the most sophisticated service mesh. Service meshes are a tool. They\u0026rsquo;re not a requirement. And for most teams, they\u0026rsquo;re unnecessary overhead.\nService mesh marketing says you need zero-trust. You need mTLS everywhere. You need service mesh. But you don\u0026rsquo;t. Application-level security works fine. Network-level security works fine. Service meshes are one option. Not the only option.\nMost teams can skip service meshes. Most teams can use simpler mechanisms. Most teams can avoid the sidecar tax entirely.\nBut if you\u0026rsquo;re running complex microservices architectures with hundreds of services, service meshes might make sense. Just understand what you\u0026rsquo;re paying for. Understand the overhead. Understand that most teams don\u0026rsquo;t need what service meshes provide.\n","permalink":"/blog/posts/service-mesh-performance-fresser/","summary":"\u003cp\u003eService meshes are everywhere. Istio. Linkerd. Consul Connect. Every microservices architecture needs one. Or so the marketing says.\u003c/p\u003e\n\u003cp\u003eBut here\u0026rsquo;s the thing: service meshes add sidecar proxies to every pod. Envoy, Istio\u0026rsquo;s sidecar, uses 50-200 MB RAM per pod. Linkerd-proxy uses 20-100 MB. Multiply by hundreds of pods. That\u0026rsquo;s gigabytes of memory just for service mesh overhead.\u003c/p\u003e\n\u003cp\u003eAll of this before your applications run. All of this just for inter-service communication. All of this overhead.\u003c/p\u003e","title":"Service Mesh: The Sidecar Tax That Eats Your Memory"},{"content":"etcd sits at the heart of Kubernetes. Before your applications run, etcd is storing cluster state, coordinating elections, and replicating data. It consumes 2-8 GB RAM per node. It requires 3-5 nodes for high availability. That\u0026rsquo;s 6-40 GB RAM just for cluster coordination.\nMost teams don\u0026rsquo;t need distributed consensus. Most teams don\u0026rsquo;t need high availability at the cluster level. Most teams are running small clusters that would work fine with a single node and backups.\nBut Kubernetes requires etcd. So teams run etcd. They pay the consensus tax. They accept the complexity. They accept the overhead.\nThe Consensus Tax Distributed consensus is expensive. etcd uses the Raft algorithm. It requires 3-5 nodes. Each node stores a full copy of the cluster state. Each node participates in consensus. Each node consumes memory and CPU.\nA 3-node etcd cluster needs 6-24 GB RAM total. Plus CPU for consensus operations. Plus network bandwidth for replication. Plus disk I/O for persistence.\nAll of this before your applications run. All of this just for cluster coordination. All of this overhead.\nSingle-node systems don\u0026rsquo;t need consensus. They\u0026rsquo;re simpler. They\u0026rsquo;re faster. They use fewer resources. But they\u0026rsquo;re not \u0026ldquo;highly available.\u0026rdquo; So teams choose etcd instead.\nThe HA Illusion High availability sounds good. But what are you making highly available? The cluster coordination layer? Is that what\u0026rsquo;s important?\nMost applications don\u0026rsquo;t need cluster-level HA. Application-level HA is different. Load balancers. Multiple application instances. Database replication. These provide HA where it matters.\nCluster coordination HA protects against etcd failures. But etcd failures are rare. And when etcd fails, the whole cluster fails anyway. So what are you protecting against?\nTeams choose etcd \u0026ldquo;because we need HA.\u0026rdquo; But they don\u0026rsquo;t need HA at the cluster coordination level. They need HA at the application level. Those are different things.\nThe Small Cluster Problem etcd makes sense for large clusters. Hundreds of nodes. Thousands of pods. Complex coordination requirements. But most clusters are small.\nA typical Kubernetes cluster has 3-10 nodes. Maybe 20-50 pods. Simple coordination requirements. etcd is overkill.\nSmall clusters don\u0026rsquo;t need distributed consensus. They don\u0026rsquo;t need 3-node etcd clusters. They don\u0026rsquo;t need the overhead. They need simple coordination. Or no coordination at all.\nTeams run etcd because Kubernetes requires it. But they don\u0026rsquo;t need what etcd provides. They\u0026rsquo;re paying for consensus they don\u0026rsquo;t use.\nThe Memory Overhead etcd stores cluster state. Every pod. Every service. Every config map. Every secret. Everything gets stored in etcd. Memory usage grows with cluster size.\nA small cluster might use 2-4 GB RAM for etcd. A medium cluster: 4-8 GB. A large cluster: 8-16 GB. Per node. Multiply by 3-5 nodes. That\u0026rsquo;s 6-80 GB RAM just for etcd.\nMost applications don\u0026rsquo;t need this much coordination. Most applications can coordinate through databases. Through message queues. Through simpler mechanisms.\nBut Kubernetes requires etcd. So teams run etcd. They accept the memory overhead. They accept the cost.\nThe Complexity Explosion etcd adds complexity. Cluster formation. Node failures. Split-brain scenarios. Backup and restore. Upgrades. All of this is complex.\nTeams need to understand Raft. They need to monitor etcd health. They need to handle etcd failures. They need to backup etcd data. They need to restore etcd from backups.\nAll of this complexity. All of this operational burden. All for cluster coordination that most teams don\u0026rsquo;t need.\nSingle-node systems are simpler. No cluster formation. No split-brain scenarios. No consensus overhead. Just backups. That\u0026rsquo;s it.\nWho Actually Needs It etcd makes sense if you have:\nLarge clusters with hundreds of nodes Complex coordination requirements Need for cluster-level high availability Teams that can operate distributed systems Most teams don\u0026rsquo;t have these requirements. Most teams have small clusters. Most teams don\u0026rsquo;t need cluster-level HA. Most teams can\u0026rsquo;t operate distributed systems effectively.\nIf you\u0026rsquo;re running a small cluster, consider alternatives. Single-node Kubernetes. Docker Swarm. Nomad. Simpler orchestration. Less overhead. Less complexity.\nIf you\u0026rsquo;re running Kubernetes, you\u0026rsquo;re stuck with etcd. But understand what you\u0026rsquo;re paying for. Understand the overhead. Understand that most teams don\u0026rsquo;t need what etcd provides.\nThe Kubernetes Dependency Kubernetes requires etcd. There\u0026rsquo;s no way around it. If you want Kubernetes, you get etcd. You pay the consensus tax. You accept the overhead.\nBut do you need Kubernetes? Most teams don\u0026rsquo;t. Most teams can use simpler orchestration. Most teams can avoid etcd entirely.\nIf you need Kubernetes, you need etcd. But if you don\u0026rsquo;t need Kubernetes, you don\u0026rsquo;t need etcd. The question is: do you need Kubernetes?\nMost teams don\u0026rsquo;t. They choose Kubernetes because it\u0026rsquo;s popular. They get etcd as a side effect. They pay the consensus tax without needing consensus.\nThe Honest Answer If you\u0026rsquo;re running fewer than 20 nodes, etcd is probably overkill. If you don\u0026rsquo;t need cluster-level HA, etcd is probably overkill. If you can\u0026rsquo;t operate distributed systems, etcd is probably overkill.\nBut if you\u0026rsquo;re running Kubernetes, you\u0026rsquo;re stuck with etcd. Kubernetes requires it. There\u0026rsquo;s no alternative.\nThe real question is: do you need Kubernetes? If you don\u0026rsquo;t, you don\u0026rsquo;t need etcd. If you do, you need etcd. But understand what you\u0026rsquo;re paying for. Understand the overhead. Understand that most teams don\u0026rsquo;t need what etcd provides.\nThe goal is to orchestrate applications, not to operate the most sophisticated consensus system. etcd is a tool. It\u0026rsquo;s required for Kubernetes. But Kubernetes isn\u0026rsquo;t required for most teams.\nMost teams can avoid etcd by avoiding Kubernetes. Most teams can use simpler orchestration. Most teams can avoid the consensus tax entirely.\nBut if you\u0026rsquo;re running Kubernetes, you\u0026rsquo;re running etcd. You\u0026rsquo;re paying the tax. You\u0026rsquo;re accepting the overhead. Just understand what you\u0026rsquo;re getting. And what you\u0026rsquo;re paying for.\n","permalink":"/blog/posts/etcd-performance-fresser/","summary":"\u003cp\u003eetcd sits at the heart of Kubernetes. Before your applications run, etcd is storing cluster state, coordinating elections, and replicating data. It consumes 2-8 GB RAM per node. It requires 3-5 nodes for high availability. That\u0026rsquo;s 6-40 GB RAM just for cluster coordination.\u003c/p\u003e\n\u003cp\u003eMost teams don\u0026rsquo;t need distributed consensus. Most teams don\u0026rsquo;t need high availability at the cluster level. Most teams are running small clusters that would work fine with a single node and backups.\u003c/p\u003e","title":"etcd: The Consensus Tax You're Probably Paying For Nothing"},{"content":"Cloud-first is the default. Every startup uses AWS. Every enterprise migrates to Azure. Every consultant recommends GCP. But here\u0026rsquo;s the thing: 37signals went from $3.2M per year to $1.3M per year after leaving the cloud. Over $10M saved in five years.\nGEICO spent a decade migrating to the cloud. Result: 2.5x higher costs. They\u0026rsquo;re not alone.\nThe cloud isn\u0026rsquo;t always cheaper. It\u0026rsquo;s often more expensive. Especially when you factor in hidden costs: egress fees, managed services, vendor lock-in.\nThe Egress Fee Trap Cloud providers charge for data leaving their network. AWS charges $0.09 per GB for the first 10 TB. Azure charges $0.05-0.08 per GB. GCP charges $0.12 per GB.\nThat doesn\u0026rsquo;t sound like much. But it adds up. High-traffic applications transfer terabytes per month. Video streaming. Data processing. API responses. Each byte costs money.\n37signals was paying $50,000 per month in egress fees alone. That\u0026rsquo;s $600,000 per year. Just for data leaving AWS. Their own hardware costs less than that.\nEgress fees are a tax on success. The more traffic you serve, the more you pay. The more successful you are, the more expensive the cloud becomes.\nSelf-hosted infrastructure has no egress fees. You pay for bandwidth once. Then you use it. No per-GB charges. No surprise bills.\nThe Managed Service Tax Cloud providers sell managed services. RDS instead of PostgreSQL. ElastiCache instead of Redis. SQS instead of RabbitMQ. Each one costs more than self-hosting.\nRDS costs 2-3x more than running PostgreSQL on EC2. ElastiCache costs 2-4x more than running Redis yourself. SQS costs per message. RabbitMQ is free.\nManaged services are convenient. They handle backups. They handle scaling. They handle maintenance. But you pay for that convenience. And you pay a lot.\nTeams choose managed services \u0026ldquo;because it\u0026rsquo;s easier.\u0026rdquo; But easier doesn\u0026rsquo;t mean cheaper. And for many companies, cheaper matters more than easier.\nThe Lock-In Problem Once you\u0026rsquo;re on a cloud provider, leaving is hard. Your infrastructure is tied to their services. Your data is in their format. Your configs use their APIs.\nMigrating means rewriting everything. Rebuilding infrastructure. Retraining teams. Months of work. Millions of dollars.\nVendor lock-in is real. And it\u0026rsquo;s expensive. Cloud providers know this. That\u0026rsquo;s why they make it easy to get in and hard to get out.\n37signals left AWS after 15 years. It took months. It cost money. But they saved $1.9M per year. The migration cost was worth it.\nMost companies never leave. They\u0026rsquo;re locked in. They accept rising costs. They accept vendor limitations. They accept that leaving is too expensive.\nThe Hidden Costs Cloud bills are complicated. EC2 instances. RDS databases. S3 storage. CloudFront CDN. Route 53 DNS. CloudWatch monitoring. Data transfer. API calls. Reserved instances. Spot instances. The list goes on.\nTeams struggle to understand their cloud bills. They add services. They forget to remove them. They over-provision. They under-optimize. Costs creep up.\nA $10,000 per month bill becomes $20,000. Then $30,000. Then $50,000. Teams don\u0026rsquo;t notice until it\u0026rsquo;s too late. By then, they\u0026rsquo;re locked in.\nSelf-hosted infrastructure has predictable costs. Hardware. Bandwidth. Power. That\u0026rsquo;s it. No surprise charges. No per-API-call fees. No per-GB transfer costs.\nThe \u0026ldquo;Cloud-First\u0026rdquo; Cargo Cult Every startup uses AWS. Every enterprise migrates to Azure. Every consultant recommends GCP. But why?\nTeams choose cloud \u0026ldquo;because everyone does it.\u0026rdquo; They don\u0026rsquo;t analyze costs. They don\u0026rsquo;t consider alternatives. They just follow the trend.\nCloud makes sense for some companies. Startups that need to scale quickly. Companies that need global infrastructure. Teams that don\u0026rsquo;t want to manage hardware.\nBut cloud doesn\u0026rsquo;t make sense for everyone. Companies with predictable workloads. Companies with data sovereignty requirements. Companies that can self-host cheaper.\nThe \u0026ldquo;cloud-first\u0026rdquo; mentality ignores alternatives. It assumes cloud is always better. It\u0026rsquo;s not. Sometimes self-hosting is cheaper. Sometimes self-hosting is simpler. Sometimes self-hosting is better.\nWho Actually Needs It Cloud makes sense if you have:\nUnpredictable workloads that need to scale quickly Global infrastructure requirements Teams that don\u0026rsquo;t want to manage hardware Compliance requirements that cloud providers meet Budget for cloud premium pricing Most companies don\u0026rsquo;t have these requirements. Most companies have predictable workloads. Most companies can self-host cheaper. Most companies just follow the trend.\nIf you\u0026rsquo;re a startup with unpredictable growth, cloud makes sense. If you\u0026rsquo;re an enterprise with predictable workloads, self-hosting might be cheaper. If you\u0026rsquo;re somewhere in between, analyze costs. Don\u0026rsquo;t assume cloud is always better.\n","permalink":"/blog/posts/cloud-hyperscalers-performance-fresser/","summary":"\u003cp\u003eCloud-first is the default. Every startup uses AWS. Every enterprise migrates to Azure. Every consultant recommends GCP. But here\u0026rsquo;s the thing: 37signals went from $3.2M per year to $1.3M per year after leaving the cloud. Over $10M saved in five years.\u003c/p\u003e\n\u003cp\u003eGEICO spent a decade migrating to the cloud. Result: 2.5x higher costs. They\u0026rsquo;re not alone.\u003c/p\u003e\n\u003cp\u003eThe cloud isn\u0026rsquo;t always cheaper. It\u0026rsquo;s often more expensive. Especially when you factor in hidden costs: egress fees, managed services, vendor lock-in.\u003c/p\u003e","title":"Cloud Hyperscalers: The $10M Lesson from 37signals"},{"content":"Microservices are everywhere. Every startup wants them. Every architect recommends them. Every conference talks about them. But here\u0026rsquo;s the thing: Amazon Prime Video cut costs by 90% by moving away from microservices back to a monolith.\nThey published a blog post about it. The microservices overhead wasn\u0026rsquo;t worth it. They moved video quality monitoring from a distributed system back to a single process. Simpler. Faster. Cheaper.\nIf Amazon, the company that popularized microservices, is moving back to monoliths, maybe microservices aren\u0026rsquo;t always the answer.\nThe Network Tax Every microservice call goes over the network. HTTP requests. gRPC calls. Message queues. Each hop adds latency. Each hop can fail.\nA monolith makes function calls. Fast. Reliable. No network involved. A microservices architecture makes network calls. Slow. Unreliable. Network involved.\nI\u0026rsquo;ve seen systems where a single user request triggers 20+ service calls. Each call adds 1-5ms latency. That\u0026rsquo;s 20-100ms just for network overhead. Before any actual work happens.\nHigh-traffic systems make millions of these calls per day. Network bandwidth costs money. Network failures cause outages. Network latency degrades user experience.\nThe network is the computer. It\u0026rsquo;s also the bottleneck.\nThe Observability Overhead Distributed systems need distributed tracing. You can\u0026rsquo;t debug a request that spans 10 services without knowing which service failed. So teams add tracing infrastructure.\nOpenTelemetry. Jaeger. Zipkin. Datadog APM. New Relic. Each service instruments itself. Each service sends traces. Storage costs explode. Query costs explode.\nA monolith generates one trace per request. A microservices architecture generates 10+ spans per request. 10x the data. 10x the cost.\nLogging gets complicated too. Logs are scattered across services. Teams add log aggregation. ELK stacks. Loki. CloudWatch. More infrastructure. More complexity. More cost.\nMetrics multiply. Each service exposes its own metrics. Prometheus scrapes everything. Storage grows. Queries slow down. Dashboards become unreadable.\nThe observability tax is real. And it\u0026rsquo;s expensive.\nThe Service Mesh Sinkhole Teams add service meshes to handle microservices complexity. Istio. Linkerd. Consul Connect. Each one adds sidecar proxies. Each proxy consumes CPU and memory.\nEnvoy, Istio\u0026rsquo;s sidecar, uses 50-200 MB RAM per pod. Linkerd-proxy uses 20-100 MB. Multiply that by hundreds of pods. That\u0026rsquo;s gigabytes of memory just for service mesh overhead.\nmTLS encryption adds CPU overhead. Every inter-service call gets encrypted and decrypted. More CPU cycles. More latency.\nService mesh configs are complex. Virtual services. Destination rules. Traffic policies. Teams spend weeks configuring service meshes. Weeks debugging service mesh issues.\nThe service mesh is supposed to simplify microservices. Instead, it adds another layer of complexity. Another layer of overhead. Another layer of things that can break.\nThe Amazon Prime Video Lesson Amazon Prime Video moved video quality monitoring from microservices to a monolith. The microservices version used AWS Step Functions, Lambda, and S3. The monolith version runs in a single process.\nResult: 90% cost reduction. Simpler architecture. Faster execution. Lower operational overhead.\nThey didn\u0026rsquo;t move everything to a monolith. They moved one specific workflow. The one that didn\u0026rsquo;t need to be distributed. The one that was simpler as a monolith.\nThe lesson: use microservices when distribution adds value. Don\u0026rsquo;t use microservices when it adds overhead.\nThe Deployment Complexity Deploying a monolith is simple. Build one artifact. Deploy to one place. Test one thing. Roll back one thing.\nDeploying microservices is complex. Build multiple artifacts. Deploy to multiple places. Test interactions between services. Roll back requires coordinating multiple deployments.\nTeams add CI/CD pipelines. Kubernetes deployments. Helm charts. ArgoCD. More infrastructure. More complexity. More things that can break.\nA simple bug fix requires deploying multiple services. A rollback requires rolling back multiple services. Coordination overhead. Risk of partial deployments. Risk of inconsistent states.\nThe deployment tax is real. And it slows down development.\nThe Team Structure Problem Microservices require team coordination. Service A depends on Service B. Changes to Service B break Service A. Teams need to coordinate. Teams need to communicate. Teams need to test together.\nConway\u0026rsquo;s Law: organizations design systems that mirror their communication structure. Microservices architectures require microservices organizations. That means more teams. More coordination. More overhead.\nSmall teams can\u0026rsquo;t maintain microservices effectively. They don\u0026rsquo;t have enough people. They can\u0026rsquo;t coordinate effectively. They end up with a distributed monolith: microservices architecture with monolith deployment practices.\nLarge organizations can maintain microservices. They have dedicated platform teams. They have service ownership. They have coordination processes. But most companies aren\u0026rsquo;t large organizations.\nWho Actually Needs It Microservices make sense if you have:\nMultiple independent teams that need to deploy independently Services with different scaling requirements Services with different technology stacks Services that need geographic distribution Clear service boundaries and well-defined APIs Most applications don\u0026rsquo;t have these requirements. Most teams can\u0026rsquo;t maintain microservices effectively. Most microservices architectures are distributed monoliths in disguise.\nIf you\u0026rsquo;re a small team, start with a monolith. If you\u0026rsquo;re a medium team, use modular monoliths. If you\u0026rsquo;re a large organization with clear service boundaries, then microservices might make sense.\nBut don\u0026rsquo;t start with microservices \u0026ldquo;because Netflix does it.\u0026rdquo; Netflix has thousands of engineers. You probably don\u0026rsquo;t.\nThe Honest Answer I genuinely don\u0026rsquo;t know how to feel about microservices. They solve real problems for large organizations. But most organizations aren\u0026rsquo;t large.\nThe honest answer: if you\u0026rsquo;re running fewer than 10 services with a small team, microservices are probably overkill. If you don\u0026rsquo;t have clear service boundaries, microservices will become a distributed monolith. If you can\u0026rsquo;t deploy services independently, you don\u0026rsquo;t have microservices. You have a distributed monolith.\nStart with a monolith. Extract services when you have clear boundaries. Extract services when you have independent teams. Extract services when distribution adds value.\nDon\u0026rsquo;t start with microservices because it\u0026rsquo;s trendy. Start with what works. Extract complexity when you need it. Not before.\nThe goal is to ship software, not to operate the most sophisticated microservices architecture. Microservices are a tool. They\u0026rsquo;re not a requirement. And for most teams, they\u0026rsquo;re premature optimization.\nAmazon Prime Video learned this. Maybe you should too.\n","permalink":"/blog/posts/microservices-performance-fresser/","summary":"Amazon Prime Video cut costs by 90% by moving away from microservices back to a monolith.","title":"Microservices: What Amazon Prime Video Learned the Hard Way"},{"content":"NGINX sits between your users and your application. Before a single request reaches your code, NGINX is parsing configs, terminating SSL, rewriting URLs, and logging everything. All of this overhead. All of this complexity.\nThe Ingress-NGINX controller is being retired in March 2026. About 50% of cloud-native setups depend on it. No more fixes. No more patches. Migrating means rewriting ingress configs across hundreds of services. Staying means increasing security risk. Pick your poison.\nThe Reverse Proxy Tax NGINX needs memory. A basic setup uses 50-100 MB RAM. Production configs with caching, rate limiting, and complex rewrites: 200-500 MB. Per instance. Before your application runs.\nCPU overhead isn\u0026rsquo;t trivial either. SSL/TLS termination chews through cycles. Every request gets parsed, matched against location blocks, rewritten, logged. High-traffic sites run multiple NGINX instances. Each one consuming resources.\nThere are teams that run NGINX in front of applications that could serve traffic directly. The reverse proxy adds latency. It adds failure points. It adds operational burden. For what?\nThe Configuration Maze nginx.conf starts simple. Then you add SSL. Then rate limiting. Then URL rewrites. Then custom headers. Then logging. Then caching. Before you know it, you\u0026rsquo;re maintaining 500+ lines of nginx.conf across multiple files.\nThe location block matching rules are arcane. Regex patterns that worked in testing break in production. Order matters. Context matters. One misplaced semicolon breaks everything.\nProduction configs average 300-800 lines. Teams spend more time debugging nginx.conf than fixing application bugs. I\u0026rsquo;ve watched engineers spend days tracing why a rewrite rule isn\u0026rsquo;t matching. Days. For a reverse proxy config.\nThe SSL Termination Cost NGINX terminates SSL/TLS. That means decrypting every incoming request and encrypting every response. CPU intensive. Memory intensive. For high-traffic sites, this is expensive.\nYou could terminate SSL at the load balancer. Or at the application. But teams default to NGINX because it\u0026rsquo;s \u0026ldquo;the standard way.\u0026rdquo; Standard doesn\u0026rsquo;t mean optimal.\nModern applications can handle TLS directly. Go, Rust, and other languages have excellent TLS libraries. The overhead is minimal. But teams still route through NGINX \u0026ldquo;just in case.\u0026rdquo;\nThe Retirement Problem The Ingress-NGINX controller is being retired in March 2026. The Kubernetes project is moving to Gateway API. Ingress-NGINX gets no more fixes, patches, or security updates.\nAbout 50% of cloud-native setups depend on Ingress-NGINX. That\u0026rsquo;s thousands of clusters. Migrating means:\nRewriting ingress configs across hundreds of services Testing new Gateway API implementations Dealing with breaking changes Potential downtime during migration Or you stay on Ingress-NGINX and accept increasing security risk. No patches means vulnerabilities accumulate. CVEs get published. Your cluster stays vulnerable.\nThis isn\u0026rsquo;t a theoretical problem. It\u0026rsquo;s happening now. Teams are scrambling to migrate or accept the risk.\nThe Observability Overhead NGINX logs everything. Access logs. Error logs. Custom logs. High-traffic sites generate gigabytes of logs per day. Storage costs add up. Parsing costs add up.\nTeams add log aggregation. ELK stacks. Loki. CloudWatch. More infrastructure. More complexity. More cost. All to handle logs from a reverse proxy.\nYour application probably logs too. So you\u0026rsquo;re parsing and storing logs twice. Once from NGINX. Once from your app. Duplicate effort. Duplicate cost.\nReal Companies Removing Layers I know teams that removed NGINX entirely. Their applications serve traffic directly. TLS termination happens at the application level. Simpler. Faster. Cheaper.\nOne team cut infrastructure costs by 30% after removing NGINX. Fewer instances to run. Less memory. Less CPU. Less operational overhead.\nAnother team moved from NGINX to Caddy. Automatic HTTPS. Simpler config. Lower resource usage. They\u0026rsquo;re happy with the switch.\nThe pattern: add NGINX \u0026ldquo;because everyone does it.\u0026rdquo; Discover the overhead. Remove it when possible. But nobody writes blog posts about removing NGINX because it\u0026rsquo;s embarrassing to admit you didn\u0026rsquo;t need it.\nWho Actually Needs It NGINX makes sense if you need:\nComplex URL rewriting across multiple backends Advanced rate limiting and DDoS protection Static file serving with caching Load balancing across multiple application instances Legacy application support (apps that can\u0026rsquo;t handle TLS directly) Most applications don\u0026rsquo;t need these. Modern applications can handle TLS. They can serve static files. They can implement rate limiting. They don\u0026rsquo;t need a reverse proxy layer.\nIf you\u0026rsquo;re running a simple API or web application, serve it directly. Use your application framework\u0026rsquo;s built-in TLS support. Skip the reverse proxy.\nIf you need load balancing, use a cloud load balancer or a simpler proxy like Caddy or Traefik. They\u0026rsquo;re easier to configure. They use fewer resources.\nThe Honest Answer I genuinely don\u0026rsquo;t know how to feel about NGINX. It solves real problems for complex setups. But most setups aren\u0026rsquo;t complex.\nThe honest answer: if your application can handle TLS and serve traffic directly, skip NGINX. If you need simple load balancing, use a cloud load balancer or Caddy. If you need complex routing, then NGINX might make sense. But most teams don\u0026rsquo;t need complex routing.\nThe goal is to serve requests, not to operate the most sophisticated reverse proxy configuration. NGINX is a tool. It\u0026rsquo;s not a requirement. And for most applications, it\u0026rsquo;s unnecessary overhead.\nWith Ingress-NGINX being retired, now is a good time to ask: do you actually need a reverse proxy? Or can your application serve traffic directly?\nMost applications can. Most teams just don\u0026rsquo;t realize it.\n","permalink":"/blog/posts/nginx-performance-fresser/","summary":"\u003cp\u003eNGINX sits between your users and your application. Before a single request reaches your code, NGINX is parsing configs, terminating SSL, rewriting URLs, and logging everything. All of this overhead. All of this complexity.\u003c/p\u003e\n\u003cp\u003eThe Ingress-NGINX controller is being retired in March 2026. About 50% of cloud-native setups depend on it. No more fixes. No more patches. Migrating means rewriting ingress configs across hundreds of services. Staying means increasing security risk. Pick your poison.\u003c/p\u003e","title":"NGINX: When Reverse Proxies Cost More Than They're Worth"},{"content":"Kubernetes was built to orchestrate Google\u0026rsquo;s global infrastructure. You are not Google. Terribly sorry.\n82% of container users run Kubernetes in production. Most of them shouldn\u0026rsquo;t.\nThe Control Plane Tax Before your application serves a single request, Kubernetes needs etcd chewing through 2-8 GB RAM per node. Then kube-apiserver, kube-scheduler, kube-controller-manager, kubelet (reserving 25% of node memory by default), CoreDNS, kube-proxy, and a CNI plugin. All of this before your code runs.\nA production high-availability cluster needs 6-12 CPU cores and 12-24 GB RAM. For orchestration. Not for your application.\nK3s calls itself the \u0026ldquo;lightweight\u0026rdquo; alternative. It still needs 1.6 GB RAM at idle. The lightest Kubernetes is heavier than most applications it runs. Marvellous.\nThe YAML Labyrinth Deploy one service on Kubernetes and you\u0026rsquo;re looking at a Deployment (20 lines), a Service (19 lines), and an Ingress (27 lines). That\u0026rsquo;s 66 lines across 3 files. Minimum.\nThe same service on FreeBSD: one rc.conf entry. On Linux: one 10-line systemd service file.\nProduction services average 200+ lines of YAML. Per service. I\u0026rsquo;ve seen teams spend more time debugging YAML indentation than fixing bugs.\nThe Waste Report Cast.ai surveyed 2,100+ organizations in 2024. The numbers are brutal:\nAverage CPU utilization: 10% Average memory utilization: 23% 87% of provisioned CPU sits idle You\u0026rsquo;re paying for 10 servers to do the work of one. Quite the bargain.\nI keep thinking about what that means. Teams provision clusters. They set resource requests and limits. They watch the monitoring dashboards. Still, 90% waste. The orchestration layer is so complex that over-provisioning feels safer than under-provisioning. So everyone over-provisions.\nThe Operational Sinkhole Komodor\u0026rsquo;s 2025 report found:\n38% of companies have high-impact outages weekly 79% of incidents get triggered by a recent change Platform teams lose 34 workdays per year on troubleshooting Kubernetes doesn\u0026rsquo;t reduce operational complexity. It adds another layer. You still deploy your application. Now you also maintain the platform that deploys your application.\nWhen something breaks, is it your code? The base image? The CNI plugin? The ingress controller? The storage driver? The control plane? Good luck figuring that out at 3am.\nThe Invoice Real companies are walking away. And saving money.\nAmazon Prime Video cut costs by 90% by moving away from microservices back to a monolith. They published a blog post about it. The orchestration overhead wasn\u0026rsquo;t worth it.\n37signals went from $3.2M per year to $1.3M per year after leaving the cloud. Over $10M saved in five years. Basecamp runs on their own hardware now.\nGEICO spent a decade migrating to the cloud. Result: 2.5x higher costs. They\u0026rsquo;re not alone.\nThe pattern is consistent. Adopt Kubernetes. Discover the tax. Quietly move back. Nobody writes blog posts about \u0026ldquo;Why We Left Kubernetes\u0026rdquo; because it\u0026rsquo;s embarrassing. But they\u0026rsquo;re leaving.\nThe Staffing Multiplier There are teams that went from 12 DevOps engineers to 3 after leaving Kubernetes. Nine engineers were maintaining the platform, not building the product.\nWhen your orchestration layer requires more engineers than your application, something is wrong. That\u0026rsquo;s not a feature. That\u0026rsquo;s a tax.\nThe Certification Economy CKA certification costs $445 per engineer. With training, you\u0026rsquo;re looking at up to $1,950. A team of five: nearly $10K. Before writing a single line of application code.\nThe complexity isn\u0026rsquo;t a bug. It\u0026rsquo;s a business model. Training companies, consulting firms, and cloud providers all benefit from Kubernetes being hard. The harder it is, the more they charge.\nWho Actually Needs It Kelsey Hightower, one of Kubernetes\u0026rsquo; most prominent advocates, said this: \u0026ldquo;There\u0026rsquo;s a lot of extra concepts, config files, and infrastructure you have to manage to do something basic.\u0026rdquo;\nIf its greatest champion calls it challenging, maybe it is.\nKubernetes makes sense if you have 50+ services across multiple regions with a dedicated platform team. That describes maybe 5% of companies running it.\nThe other 95% need a server, a process manager, and the courage to admit it.\nWhat\u0026rsquo;s Breaking Right Now (February 2026) The problems aren\u0026rsquo;t getting better.\nIngress-NGINX Controller Retirement The Ingress-NGINX controller is being retired in March 2026. No more fixes, patches, or updates. About 50% of cloud-native setups depend on it. Staying on it means increasing security risk. Migrating means rewriting ingress configs across hundreds of services. Pick your poison.\nSecurity Vulnerabilities Multiple CVEs from 2025-2026: config injection, auth bypass, DoS in ingress components. Credential caching flaws. Certificate validation issues. Some earlier flaws allowed unauthenticated remote code execution and full cluster compromise.\nThe attack surface is huge. Misconfigurations. Overly permissive RBAC. Insecure defaults. These aren\u0026rsquo;t edge cases. They\u0026rsquo;re common.\nComplexity and Operational Pain Upgrades break APIs. Operators lag behind. Networking and storage issues appear out of nowhere. Minor releases feel like migrations. Teams I\u0026rsquo;ve talked to budget a week for every Kubernetes upgrade. A week. For a minor version bump.\nDependency Risk Cloud outages affect Kubernetes services. Azure incidents in 2025 took down managed Kubernetes clusters. When your orchestration layer depends on cloud infrastructure, you inherit all of its problems.\nThe Honest Answer I genuinely don\u0026rsquo;t know how to feel about Kubernetes. It solves real problems for companies at Google\u0026rsquo;s scale. But most companies aren\u0026rsquo;t at Google\u0026rsquo;s scale.\nThe honest answer: if you\u0026rsquo;re running fewer than 20 services, Kubernetes is probably overkill. If you don\u0026rsquo;t have a dedicated platform team, Kubernetes will consume your engineering time. If you\u0026rsquo;re not multi-region, Kubernetes adds complexity without clear benefits.\nUse systemd. Use Docker Compose. Use Nomad. Use whatever gets your code running with the least overhead.\nThe goal is to ship software. Not to operate the most sophisticated orchestration platform. Kubernetes is a tool. It\u0026rsquo;s not a religion. And for most teams, it\u0026rsquo;s the wrong tool.\n","permalink":"/blog/posts/kubernetes-performance-fresser/","summary":"\u003cp\u003eKubernetes was built to orchestrate Google\u0026rsquo;s global infrastructure. You are not Google. Terribly sorry.\u003c/p\u003e\n\u003cp\u003e82% of container users run Kubernetes in production. Most of them shouldn\u0026rsquo;t.\u003c/p\u003e\n\u003ch2 id=\"the-control-plane-tax\"\u003eThe Control Plane Tax\u003c/h2\u003e\n\u003cp\u003eBefore your application serves a single request, Kubernetes needs etcd chewing through 2-8 GB RAM per node. Then kube-apiserver, kube-scheduler, kube-controller-manager, kubelet (reserving 25% of node memory by default), CoreDNS, kube-proxy, and a CNI plugin. All of this before your code runs.\u003c/p\u003e","title":"Kubernetes: The Orchestration Tax Most Teams Don't Need"},{"content":"When teams talk about platform architecture, they focus on big services, routing layers, and deployment workflows.\nBut a lot of day-to-day reliability comes from smaller building blocks, especially cache primitives.\nThe overlooked part of platform quality In distributed systems, it is easy to create accidental complexity:\nrepeated expensive lookups duplicated state checks inconsistent retry behavior extra allocation and lock pressure A lightweight TTL cache does not solve everything, but it solves many of these local inefficiencies in a predictable way.\nWhy this matters in real code A basic cache primitive usually offers only a few operations:\nPut Get Len New That small API surface is a feature, not a limitation.\nIt keeps behavior understandable, makes integration easy across packages, and reduces accidental misuse.\nThe practical value of \u0026ldquo;basic\u0026rdquo; design Simple cache layers help platform teams in three ways:\nPerformance Frequently reused values are served without repeated expensive work. Clarity Engineers can reason about behavior quickly because the primitive is narrow and explicit. Maintenance Shared utility logic prevents copy-pasted caching code across services. In other words, small utilities create compounding benefits at system scale.\nWhy TTL is a good default In fast-moving systems, data freshness matters as much as speed.\nTTL-based caching gives a straightforward contract:\nvalues are reusable for a bounded window stale state naturally expires callers do not need custom invalidation logic for every small use case This is often the right trade-off for metadata, short-lived lookups, and helper-layer optimizations.\nCommon mistakes teams make introducing complex cache frameworks before proving need adding cache logic independently in multiple services caching without explicit expiration behavior treating cache state as source of truth A basic primitive avoids most of these pitfalls by keeping intent explicit.\nFinal takeaway Platform quality is not only defined by large subsystems.\nSmall shared primitives, like a minimal TTL cache, reduce duplication and improve consistency across the codebase. Over time, that makes distributed systems easier to scale and easier to operate.\n","permalink":"/blog/posts/why-small-cache-primitives-matter-in-distributed-platforms/","summary":"A practical look at why simple TTL cache primitives improve clarity, performance, and reliability in distributed platform codebases.","title":"Why Small Cache Primitives Matter in Distributed Platforms"},{"content":"Raft isn\u0026rsquo;t the flex. Operations are. That\u0026rsquo;s why Taubyte\u0026rsquo;s Raft feels tougher. Most Raft implementations look great in theory and fall apart in practice. The algorithm itself isn\u0026rsquo;t the problem. It\u0026rsquo;s everything around the algorithm that breaks in production: bootstrapping, discovery, leader routing, rejoin behavior, and what happens when nodes start out of order or the network is unreliable.\nTaubyte\u0026rsquo;s Raft (pkg/raft) wraps HashiCorp Raft and adapts it with libp2p transport, Taubyte discovery, and datastore-backed persistence. The goal isn\u0026rsquo;t to reinvent consensus. It\u0026rsquo;s to make consensus operable. Nodes can start in any order and converge to a working cluster without static seed lists or fragile bootstrap rituals. (GitHub)\nWhat Taubyte adds Discovery-first startup Classic Raft deployments fail at cluster formation. If that step goes wrong, you get split clusters, stranded nodes, or manual recovery procedures.\nTaubyte designs startup around discovery and peer exchange. Nodes observe what\u0026rsquo;s alive, coordinate, and decide whether they\u0026rsquo;re founders or joiners. The README explicitly calls out messy real-world cases it\u0026rsquo;s meant to handle: simultaneous startup, staggered startup, partial connectivity, and nodes joining immediately after formation. (GitHub)\nAutomatic leader forwarding Most Raft systems require clients to implement leader discovery: retries, redirects, backoff logic, edge cases under load. Every client application eventually reimplements this with slightly different bugs.\nTaubyte pushes this into the service layer. Operations that must hit the leader are forwarded automatically. Clients can talk to any reachable node and still make progress. (GitHub) This reduces failure modes when systems are under stress. When the leader changes, clients don\u0026rsquo;t need to know. They just keep working.\nRejoin and recovery as first-class scenarios Resilience isn\u0026rsquo;t a slogan. It\u0026rsquo;s whether a follower can disappear, reboot, and rejoin cleanly. It\u0026rsquo;s whether the cluster survives leader restarts without operator intervention.\nTaubyte treats rejoin, reboot, and leader reboot as expected behaviors, covered by integration tests. (GitHub) These aren\u0026rsquo;t edge cases. They\u0026rsquo;re expected behaviors the system is designed to handle gracefully.\nBuilt-in security Optional AES-256-GCM encryption for both Raft transport and the command layer, using a shared key across members. (GitHub) You don\u0026rsquo;t need to wrap it in TLS or build encryption layers yourself.\nWhy Kubernetes \u0026ldquo;Raft\u0026rdquo; feels fragile Kubernetes relies on etcd as its source of truth. etcd uses Raft, and the Raft core is solid. The fragility comes from dependency shape.\nWhen etcd struggles, the entire control plane struggles. Kubernetes documentation is explicit: etcd performance is sensitive to disk and network I/O, and resource starvation triggers heartbeat timeouts and cluster instability. When that happens, the cluster can\u0026rsquo;t make changes, including scheduling new pods. (Kubernetes)\nThe operational rule becomes: don\u0026rsquo;t touch etcd. It\u0026rsquo;s treated like a delicate organ because everything depends on it. You can\u0026rsquo;t upgrade it casually. You can\u0026rsquo;t restart it without careful planning. You monitor it obsessively because if it goes down, everything goes down.\nTaubyte\u0026rsquo;s model treats consensus as a primitive, not a fragile external dependency. It tolerates churn and keeps moving. (GitHub) Nodes can come and go, and the system adapts. It\u0026rsquo;s not a single point of failure that brings down the entire platform.\nComparison to typical Raft libraries HashiCorp Raft provides a replicated log and FSM for building state machines. It\u0026rsquo;s powerful, but it\u0026rsquo;s just a library. (GitHub) You get the consensus algorithm, but you\u0026rsquo;re responsible for the hardest parts in practice: discovery, transport behavior, leader routing, startup sequencing, and safe rejoin flows.\nThis means every team building on HashiCorp Raft ends up solving the same problems, making the same mistakes, and learning the same lessons the hard way.\nTaubyte keeps the proven Raft core and productizes the operational layer until it behaves like a platform component. (GitHub) You get the consensus algorithm and the operational intelligence that makes it work in production.\nConcern Taubyte Raft Kubernetes / etcd Typical Raft library Startup Nodes start in any order and converge via discovery (GitHub) Control plane tightly coupled to etcd health (Kubernetes) You design bootstrap and discovery yourself (GitHub) Leader handling Automatic leader forwarding (GitHub) Works, but instability blocks cluster changes (Kubernetes) Usually handled in client/app code (GitHub) Churn \u0026amp; recovery Rejoin and reboot are expected paths (GitHub) Sensitive to disk/network I/O and starvation (Kubernetes) Depends entirely on your wrappers Security Built-in transport + command encryption (GitHub) Secured via deployment and hardening choices (Kubernetes) Delegated to external layers Takeaway Kubernetes doesn\u0026rsquo;t suffer because Raft is weak. It suffers because the platform is tightly coupled to a quorum datastore whose performance is sensitive to real-world conditions. When that component wobbles, everything stalls. (Kubernetes)\nTaubyte\u0026rsquo;s Raft makes consensus boring to operate: discovery-first startup, leader-transparent requests, expected recovery paths, and built-in security. That\u0026rsquo;s why it feels more autonomous and resilient in practice, even though it\u0026rsquo;s built on a standard Raft core. (GitHub)\n","permalink":"/blog/posts/why-raft-fails-in-production-and-how-taubyte-raft-fixes-it/","summary":"Most Raft implementations look great in theory and fall apart in practice. The algorithm itself isn\u0026rsquo;t the problem—it\u0026rsquo;s everything around the algorithm that breaks in production: bootstrapping, discovery, leader routing, rejoin behavior, and what happens when nodes start out of order or the network is unreliable. Taubyte\u0026rsquo;s Raft wraps HashiCorp Raft and adapts it with libp2p transport, Taubyte discovery, and datastore-backed persistence. The goal isn\u0026rsquo;t to reinvent consensus—it\u0026rsquo;s to make consensus operable. Nodes can start in any order and converge to a working cluster without static seed lists or fragile bootstrap rituals. This article explores how Taubyte\u0026rsquo;s Raft addresses the operational challenges that make Kubernetes/etcd fragile and compares it to typical Raft libraries.","title":"Why Raft Fails in Production and How Taubyte Raft Fixes It"},{"content":"Secret management used to be a mostly solved problem. You picked a system, stored secrets, added policies, rotated keys occasionally, and moved on.\nBut two things have changed:\nEverything is distributed now: multi-node, multi-region, constant churn. Secrets are consumed continuously: by automation, services, agents, and toolchains. The rise of AI agents and agentic workflows shifts the problem significantly:\nSecrets get fetched more often (and often repeatedly) Workflows fan out and retry automatically Tool calls chain across components you don\u0026rsquo;t fully control Temporary state tends to become permanent (logs, caches, artifacts, traces) The speed of failure is now minutes, not weeks So the old secret-management question, \u0026ldquo;Who is allowed to read the secret?\u0026rdquo;, stops being the useful one.\nThe question that matters is:\nWho is cryptographically capable of ever seeing plaintext?\nBecause wherever plaintext exists, it can be logged, scraped from memory, accessed through debugging, exposed by misconfiguration, or exfiltrated after compromise.\nAs autonomy increases, \u0026ldquo;least privilege\u0026rdquo; alone doesn\u0026rsquo;t save you if plaintext exists in too many places.\nThe comparison that actually matters This isn\u0026rsquo;t a feature checklist. It\u0026rsquo;s a threat-model comparison: where plaintext can exist, what breaks confidentiality, and how big the blast radius is.\nDimension Taubyte HashiCorp Vault Kubernetes Secrets Trust model Crypto-trusted (servers can\u0026rsquo;t decrypt) Process-trusted Admin-trusted Where plaintext can exist Client boundary only Vault server memory Control plane, nodes, and pods Server can read secrets ✅ No (by design) ❌ Yes (transient) ❌ Yes Operator can read secrets ✅ No Possible with privilege/compromise ❌ Yes (by design) Key creation / rotation Continuous and automatic Init + operational rekey None by default What breaks confidentiality Client compromise or threshold compromise + ciphertext access Server/process compromise or privileged token Cluster admin/node/pod compromise Blast radius on compromise Bounded per secret Potentially all secrets Often cluster-wide If you only internalize one row, make it this one:\nWhere plaintext can exist.\nThat\u0026rsquo;s the whole game.\nKubernetes Secrets: low effort, weakest model Kubernetes Secrets are popular because they\u0026rsquo;re convenient and native. But it helps to call them what they are: a configuration distribution mechanism, not a high-security vault.\nKubernetes Secrets are stored as objects in the cluster, distributed to workloads, accessible to administrators by design, and present at runtime in places that are hard to fully control: nodes, pods, environment variables, files.\nEven with encryption-at-rest enabled, secrets still exist in plaintext at runtime because the whole point is to inject them into applications.\nThe key question: How many components in your cluster can touch plaintext?\nIn Kubernetes, the answer is: a lot.\nThat may be acceptable for low-to-medium value secrets, internal services, or environments with mature cluster hardening. But for high-value secrets in agent-heavy workflows, it\u0026rsquo;s too much surface area.\nVault: real secret management, still a decrypting authority Vault is a real secret manager, and it\u0026rsquo;s the right answer for many organizations. It gives you centralized control, strong auth and policy, auditing, dynamic secrets, and rotation workflows teams can operate reliably.\nBut Vault has an unavoidable property:\nIf Vault returns plaintext to a client, plaintext must exist inside Vault at runtime.\nThat\u0026rsquo;s not a criticism. It\u0026rsquo;s physics.\nVault\u0026rsquo;s model is best described as \u0026ldquo;trust the process, not the humans.\u0026rdquo; Operators shouldn\u0026rsquo;t read secrets. Policies restrict access. Storage is encrypted. Auditing is possible.\nBut Vault is still a centralized service that can decrypt and serve secrets. Compromise of the wrong layer (process, host, or privileged access) can widen the blast radius quickly.\nVault reduces the number of humans who can get secrets. It does not remove secrets from the server\u0026rsquo;s trust boundary.\nTaubyte: secret management without server trust Taubyte starts with a different premise:\nAssume the server gets compromised. Make that insufficient.\nInstead of building \u0026ldquo;the best possible decrypting server,\u0026rdquo; Taubyte builds a system where servers cannot decrypt at all.\nThe design ensures:\nSecrets are encrypted before they reach the platform No single component holds enough information to decrypt Decryption happens only at the client boundary Infrastructure compromise doesn\u0026rsquo;t automatically become a credential leak In practical terms:\nNo server process sees plaintext No operator has a \u0026ldquo;read everything\u0026rdquo; lever Compromise of a single node doesn\u0026rsquo;t break confidentiality The blast radius is naturally bounded per secret This is what \u0026ldquo;zero-knowledge server-side\u0026rdquo; looks like operationally: the system can store and serve secrets without being able to learn them.\nNo master key, no ceremony Traditional systems require key ceremonies, unsealing, and recovery workflows. Taubyte eliminates this entirely. Keys are distributed and rotate automatically in the background.\nThere\u0026rsquo;s no centralized master key to protect, no unseal ceremony when nodes restart, and no recovery workflow that depends on privileged key custodians.\nThe operational burden is effectively zero because the hard part (key lifecycle management) is automated by design.\nThreat model: what breaks, and how bad is it? This is where teams either sleep at night or don\u0026rsquo;t.\nKubernetes Secrets break when anything compromises the cluster trust boundary: admin access, node compromise, or workload compromise with broad permissions. Impact is often wide because secrets exist broadly at runtime.\nVault breaks when the decrypting authority is compromised: Vault host or process, privileged token, or policy/auth boundary failure. Impact can become wide quickly because Vault is the centralized service that returns plaintext.\nTaubyte requires compromising the only place plaintext exists (the client boundary), or breaking the distributed threshold across multiple nodes plus accessing that specific secret\u0026rsquo;s encrypted data. Impact is naturally bounded per secret.\nA short way to say it:\nTaubyte failure exposes a secret. Vault or K8s failure can expose a system.\nWhy this matters for AI agents In agent-driven systems, secrets are no longer rare events. They\u0026rsquo;re background capabilities.\nA single agent workflow might:\npull credentials to call an internal API, fetch another token to reach a data warehouse, then call a third service through an MCP toolchain. That can happen hundreds or thousands of times per hour, often with retries and parallelism.\nSystems that depend on perfect tokens, perfect hosts, perfect policies, and perfect humans will eventually fail. Not because teams are incompetent, but because scale makes edge cases inevitable.\nThe safest direction is to reduce the number of places plaintext can exist to the smallest boundary possible.\nTaubyte\u0026rsquo;s design does exactly that: plaintext exists at the client boundary, not the server boundary.\nChoosing a model intentionally In the AI era, Taubyte is the best default because it delivers enterprise-grade secret management while keeping breach impact contained.\nChoose Kubernetes Secrets when you want the simplest, platform-native way to ship secrets to workloads, and you are comfortable trusting your cluster admins and control plane.\nChoose Vault when you need centralized policy, audit trails, and compliance reporting, and you are comfortable running a centralized service that decrypts secrets on demand.\nChoose Taubyte when you want an infrastructure breach to be a contained incident, not a credential leak, and when you want secret management that stays safe even as your systems become autonomous.\nClosing thought Secret management isn\u0026rsquo;t fundamentally about storage. It\u0026rsquo;s about trust boundaries.\nKubernetes Secrets → trust admins and nodes Vault → trust the process Taubyte → trust cryptography and keep plaintext client-side As AI agents become a normal part of production workflows, the only direction that scales safely is the one that minimizes plaintext exposure.\nWhere plaintext lives determines your risk surface.\nEverything else is implementation detail.\n","permalink":"/blog/posts/secrets-for-ai-era/","summary":"Secret management in the age of AI agents requires rethinking trust boundaries. The critical question is no longer who can access secrets, but where plaintext can ever exist.","title":"Secrets in the AI Era: Where Plaintext Lives"},{"content":"Secret management used to be a mostly solved problem. You picked a system, stored secrets, added policies, rotated keys occasionally, and moved on.\nBut the environment around secrets has changed faster than most security models did.\nTwo shifts are driving that change:\nEverything is distributed now: multi-node, multi-region, constant churn, ephemeral workloads. Secrets are consumed continuously: by automation, microservices, agents, and toolchains. The rise of AI agents and agentic workflows amplifies both shifts:\nSecrets get fetched more often (and repeatedly) Workflows fan out and retry automatically Tool calls chain across components you don’t fully control Temporary state tends to become permanent (logs, caches, artifacts, traces) The speed of failure is now minutes, not weeks So the old secret-management question, \u0026ldquo;Who is allowed to read the secret?\u0026rdquo;, stops being the useful one.\nThe question that matters is:\nWho is cryptographically capable of ever seeing plaintext?\nBecause wherever plaintext exists, it can be logged, scraped from memory, accessed through debugging, exposed by misconfiguration, or exfiltrated after compromise.\nAs autonomy increases, \u0026ldquo;least privilege\u0026rdquo; helps, but it doesn’t save you if plaintext exists in too many places.\nThe mental model: trust boundaries, not feature sets The easiest way to get misled in security is to compare tools by feature count.\nSecret systems tend to look similar on paper:\nstore a secret retrieve a secret rotate a secret apply policy But the defining difference between them is where the trust boundary is drawn.\nA secret system is really a statement about what you’re willing to trust:\nAdmin-trusted systems assume privileged humans and infrastructure are trusted. Process-trusted systems assume the right service can safely handle plaintext. Crypto-trusted systems assume infrastructure is hostile and design plaintext out of the platform. Once you see it this way, secret management becomes a risk + operational tradeoff decision, not a product decision.\nThe comparison that actually matters This isn’t a feature checklist. It’s a threat-model comparison: where plaintext can exist, what breaks confidentiality, and how big the blast radius is.\nDimension Taubyte HashiCorp Vault Kubernetes Secrets Trust model Crypto-trusted (servers can’t decrypt) Process-trusted Admin-trusted Where plaintext can exist Client boundary only Vault server memory Control plane, nodes, and pods Server can read secrets ✅ No (by design) ❌ Yes (transient) ❌ Yes Operator can read secrets ✅ No Possible with privilege/compromise ❌ Yes (by design) Key creation / rotation Continuous + automatic Init + operational rekey None by default Operational ceremony Low ceremony (hands-off lifecycle) Medium/High (init/unseal discipline + policy hygiene) Low (but weakest trust model) What breaks confidentiality Client compromise or threshold compromise + ciphertext access Process/host compromise or privileged token Cluster admin/node/pod compromise Impact (who is affected) Bounded per secret Potentially all secrets Often cluster-wide If you only internalize one row, make it this one:\nWhere plaintext can exist.\nThat’s the whole game.\nA simple map of plaintext exposure This is the cleanest way I know to explain the difference.\nflowchart LR subgraph K8S[\u0026#34;Kubernetes Secrets\u0026#34;] K1[Control Plane] --\u0026gt; K2[Node / Kubelet] K2 --\u0026gt; K3[Pod Runtime] K3 --\u0026gt; K4[Application] K4 --\u0026gt; K5[Plaintext exists across multiple boundaries] end subgraph VAULT[\u0026#34;Vault\u0026#34;] V1[Encrypted Storage] --\u0026gt; V2[Vault Server Process] V2 --\u0026gt; V3[Application] V3 --\u0026gt; V4[Plaintext exists in Vault + client] end subgraph TAU[\u0026#34;Taubyte\u0026#34;] T1[Encrypted Secret Store] --\u0026gt; T2[Nodes return crypto shares] T2 --\u0026gt; T3[Client reconstructs secret] T3 --\u0026gt; T4[Plaintext exists only client-side] end Model 1: Kubernetes Secrets (admin-trusted, broad exposure) Kubernetes Secrets are popular because they’re convenient and native.\nBut in risk terms, Kubernetes Secrets are fundamentally:\nA mechanism to deliver sensitive configuration to workloads inside the cluster trust boundary.\nThat can be perfectly fine, as long as you accept what it implies.\nHow secrets flow in Kubernetes This diagram is intentionally simplified, because the key point isn’t implementation. It’s where plaintext shows up.\nsequenceDiagram participant Admin as Admin / CI participant API as kube-apiserver participant ETCD as etcd / storage participant Node as Node (kubelet) participant Pod as Pod / Container participant App as Application Admin-\u0026gt;\u0026gt;API: Create/Update Secret API-\u0026gt;\u0026gt;ETCD: Persist secret object Node-\u0026gt;\u0026gt;API: Fetch secret for scheduled pod API--\u0026gt;\u0026gt;Node: Secret data Node--\u0026gt;\u0026gt;Pod: Mount / inject secret Pod--\u0026gt;\u0026gt;App: Env var / file read What breaks confidentiality in Kubernetes Secrets Kubernetes Secrets break when the cluster boundary breaks:\nadmin credential compromise node compromise overly permissive RBAC workload compromise with access to secrets debugging workflows that expose env/mounts Why the blast radius tends to be wide Kubernetes is designed for availability and orchestration.\nThat’s great for running workloads, but it means:\nsecrets are accessible in many places secrets are delivered to many pods nodes are involved by necessity privileged access is a normal operational tool This doesn’t mean “never use Kubernetes Secrets.”\nIt means: don’t pretend the model is cryptographically isolated. It’s admin-trusted by nature.\nModel 2: Vault (process-trusted, centralized decrypting authority) Vault is a serious system used by serious teams.\nIt gives you:\ncentralized policy and access control authentication integration audit trails rotation workflows dynamic secrets engines It solves a major problem Kubernetes doesn’t solve well:\nReducing human access to secrets while adding governance.\nBut Vault has one unavoidable property:\nIf Vault returns plaintext to a client, plaintext must exist inside Vault at runtime.\nThat’s not an opinion. It’s physics.\nHow secrets flow in Vault This is the flow most teams run in production:\nsequenceDiagram participant App as Application participant Vault as Vault participant Store as Encrypted Storage App-\u0026gt;\u0026gt;Vault: Authenticate (token / auth method) Vault-\u0026gt;\u0026gt;Store: Read encrypted secret Store--\u0026gt;\u0026gt;Vault: Ciphertext Vault--\u0026gt;\u0026gt;App: Plaintext secret What breaks confidentiality in Vault Vault breaks when the decrypting authority is compromised:\nVault host compromise Vault process compromise privileged token compromise policy/auth boundary failure Vault reduces the number of humans who can retrieve secrets. But it does not remove secrets from the server trust boundary.\nWhy the blast radius can become large Vault is usually a central service serving many workloads.\nSo compromise tends to have this shape:\nif the Vault process is compromised at runtime or a high-privilege token is obtained or the auth boundary is misconfigured …impact can expand rapidly.\nAgain: Vault is an excellent tool. But it’s a process-trusted model, not a cryptographic isolation model.\nModel 3: Taubyte (crypto-trusted, plaintext never exists server-side) Taubyte starts with a different premise:\nAssume infrastructure gets compromised. Make that insufficient.\nInstead of focusing on “who is allowed to decrypt,” Taubyte focuses on:\nNo server can decrypt at all, even if it wants to.\nThe core idea (without implementation details) Taubyte uses distributed threshold cryptography:\nencrypt with a public key decryption requires k-of-n shares no single node can decrypt alone plaintext reconstruction happens only at the client boundary How storing a secret works in Taubyte The biggest difference is where encryption happens.\nsequenceDiagram participant Client as Client / App participant Service as Taubyte Secret Service participant Store as Encrypted Secret Store Client-\u0026gt;\u0026gt;Client: Encrypt secret locally Client-\u0026gt;\u0026gt;Service: Store ciphertext + metadata Service-\u0026gt;\u0026gt;Store: Persist encrypted secret Store--\u0026gt;\u0026gt;Service: OK Service--\u0026gt;\u0026gt;Client: OK The platform stores and coordinates encrypted material. It never needs plaintext to function.\nHow retrieving a secret works in Taubyte Retrieval is where threshold changes everything:\nsequenceDiagram participant Client as Client / App participant Service as Secret Service participant NodeA as Node A participant NodeB as Node B participant NodeC as Node C Client-\u0026gt;\u0026gt;Service: Get encrypted secret (ciphertext) Service--\u0026gt;\u0026gt;Client: Ciphertext + quorum info Client-\u0026gt;\u0026gt;NodeA: Request decrypt share Client-\u0026gt;\u0026gt;NodeB: Request decrypt share Client-\u0026gt;\u0026gt;NodeC: Request decrypt share NodeA--\u0026gt;\u0026gt;Client: Partial decrypt share NodeB--\u0026gt;\u0026gt;Client: Partial decrypt share NodeC--\u0026gt;\u0026gt;Client: Partial decrypt share Client-\u0026gt;\u0026gt;Client: Combine \u0026gt;= k shares Client-\u0026gt;\u0026gt;Client: Decrypt locally → plaintext The trust boundary becomes obvious Nodes never produce plaintext Shares alone are not secrets Plaintext exists only in the client That’s what “crypto-trusted” means in real operational terms.\nKey lifecycle: continuous vs one-time ceremony This matters more than people admit.\nMany security failures are not cryptographic failures. They’re lifecycle failures:\nkey custody complexity rekey and recovery mishaps operational rituals executed under stress This is where the models differ:\nKubernetes: typically no dedicated key lifecycle by default Vault: init + unseal/recovery model, rekey is operational Taubyte: continuous rolling keys as part of normal operation Here’s a simplified view of the lifecycle patterns:\nflowchart LR subgraph K8S[\u0026#34;Kubernetes Secrets\u0026#34;] K0[No key lifecycle by default] --\u0026gt; K1[Runtime distribution relies on cluster trust] end subgraph VAULT[\u0026#34;Vault\u0026#34;] V0[Initialize once] --\u0026gt; V1[Operate with unseal/recovery discipline] V1 --\u0026gt; V2[Rekey / rotation as an operational event] end subgraph TAU[\u0026#34;Taubyte\u0026#34;] T0[Rolling key lifecycle] --\u0026gt; T1[Automatic refresh over time] T1 --\u0026gt; T2[Prefer stronger / newer keys by design] end The point isn’t “rotation exists.” The point is how dependent you are on humans doing ceremonies under pressure.\nThreat model: what breaks confidentiality, and how bad is it? This is where teams either sleep at night or don’t.\nKubernetes Secrets Break condition: compromise the cluster trust boundary\nadmin access compromised node compromised workloads over-permissioned secrets visible through debug paths Impact: often broad\nsecrets widely available in runtime contexts Vault Break condition: compromise the decrypting authority\nserver/process compromise privileged token compromise auth boundary failure Impact: can become broad quickly\nbecause the central service is capable of returning plaintext Taubyte Break condition: compromise the only place plaintext exists (client), or compromise threshold shares and access the target ciphertext.\nImpact: naturally bounded per secret\nbecause ciphertext access matters and secret material is not centrally decryptable A short way to say it:\nTaubyte failure exposes a secret. Vault or Kubernetes failure can expose a system.\nWhy AI agents push this from “nice-to-have” to necessary In agent-driven systems, secrets aren’t rare reads. They become background capabilities.\nA single agent workflow might:\nfetch an API credential call an internal tool via MCP retrieve a second token for a datastore call a third-party service retry on failure across different nodes/regions That can happen hundreds or thousands of times per hour, with parallelism.\nAt that point, security failures look less like:\n“Someone intentionally stole the key”\n…and more like:\n“The system touched plaintext in too many places, too often.”\nSo the strategic move isn’t only tighter policy. It’s reducing plaintext exposure to the smallest possible boundary.\nTaubyte does exactly that: plaintext exists at the client boundary, not the server boundary.\nAvailability vs confidentiality: the real trade you’re making Every secret system balances:\nConfidentiality (who can learn secrets) Availability (who can use secrets reliably) Kubernetes Secrets optimize availability by distributing secrets widely inside a trusted cluster.\nVault balances availability and governance with a centralized service.\nTaubyte delivers high availability like the others, but it shifts the trust boundary so the platform can keep serving secrets without becoming a single point of decryption or a single point of compromise.\nIn the AI era, Taubyte is the winner, period.\nChoosing a model intentionally You don’t pick a secret system because it’s “best.” You pick it because it matches your threat model and operational reality.\nChoose Kubernetes Secrets when: secrets are low/medium value workloads are well-contained cluster admins and nodes are trusted you want the simplest native mechanism Choose Vault when: centralized policy and auditability are critical dynamic secrets matter you accept server-side plaintext handling as part of the model you can operate the platform with strong discipline Choose Taubyte when: you want infrastructure compromise to be a contained incident you want the platform to be incapable of decrypting secrets you expect secrets to be consumed continuously by automation and agents you want blast radius bounded per secret by design Closing thought Secret management isn’t fundamentally about storage. It’s about trust boundaries.\nKubernetes Secrets → trust admins and nodes Vault → trust the process Taubyte → trust cryptography and keep plaintext client-side As AI agents become normal in production workflows, the only direction that scales safely is the one that minimizes plaintext exposure.\nWhere plaintext lives determines your risk surface.\nEverything else is implementation detail.\n","permalink":"/blog/posts/secrets-for-ai-ear-deep-dive/","summary":"A deep dive into secret management threat models in the age of AI agents. The critical question is no longer who can access secrets, but where plaintext can ever exist, and what that implies for risk, blast radius, and operational burden.","title":"Secrets in the AI Era: Where Plaintext Lives (Deep Dive)"},{"content":"Most platform slowdowns do not come from coding. They come from setup.\nTeams lose time deciding folder structure, resource naming, and project wiring before they can ship anything useful.\nThis is exactly where a Cloud Development Kit (CDK) style approach helps.\nWhat CDK means in practice At a practical level, CDK is about project scaffolding and templates.\nThat sounds simple, but it changes developer workflow in important ways:\nless manual setup fewer early-stage mistakes consistent project shape across team members faster onboarding for new contributors When the starting point is opinionated and repeatable, teams can focus on product logic sooner.\nWhy scaffolding matters for cloud projects Cloud-native projects often mix several concerns from day one:\nruntime behavior configuration layout resource definitions deployment expectations Without a scaffold, every team invents these patterns on the fly. That leads to drift and rework.\nWith templates, you standardize those decisions up front.\nThe hidden value: shared team language Scaffolding is not only about files. It creates a common team language.\nWhen every project starts from familiar structure:\nreviews are faster troubleshooting is easier docs stay more accurate automation scripts become reusable This is a compounding advantage as the number of projects grows.\nGood CDK behavior for platform teams A useful CDK layer should be:\nMinimal Avoid excessive generated complexity. Opinionated Encode proven defaults so teams avoid avoidable mistakes. Transparent Generated structure should be easy to understand and modify. Extensible Teams can adapt the scaffold without breaking future workflows. If a scaffold cannot be understood by new contributors, it becomes another form of friction.\nCommon anti-patterns generating too much boilerplate too early hiding critical conventions inside opaque templates treating scaffolds as rigid rules instead of guided defaults skipping template updates as platform practices evolve CDK helps when it accelerates learning and delivery, not when it locks teams into complexity.\nFinal takeaway Tau\u0026rsquo;s CDK direction is valuable because it optimizes the most expensive phase in many projects: the beginning.\nBy reducing setup ambiguity and standardizing initial structure, scaffolding gives teams a faster path from \u0026ldquo;new project\u0026rdquo; to \u0026ldquo;working platform workflow.\u0026rdquo;\n","permalink":"/blog/posts/inside-tau-cdk-how-scaffolding-reduces-platform-friction/","summary":"How Tau\u0026rsquo;s Cloud Development Kit approach helps teams start faster with fewer setup mistakes and more repeatable project structure.","title":"Inside Tau CDK: How Scaffolding Reduces Platform Friction"},{"content":"When you\u0026rsquo;re ready to deploy your Taubyte project to production, the process is straightforward. Whether you\u0026rsquo;ve been developing locally with Dream or directly on GitHub, you can ship your project to a production Taubyte cloud with just a few steps.\nThe deployment process involves:\nImporting your project into your production cloud Triggering builds for your repositories That\u0026rsquo;s it. Let\u0026rsquo;s walk through it.\nImporting Your Project You can import using either the web console or the Tau CLI. The web console is the easiest, so we\u0026rsquo;ll use that here.\nStep 1: Connect to Your Production Cloud If you\u0026rsquo;re currently connected to Dream, log out first.\nThen:\nNavigate to console.taubyte.com Select Custom from the network dropdown Enter your cloud\u0026rsquo;s FQDN (e.g., mycloud.example.com) Click Validate Log in with GitHub as usual Step 2: Import the Project On the projects page:\nClick Import Project Select the repository you want to import The web console will automatically identify eligible repositories. If you choose a config repo, it can even match the corresponding code repo.\nIf you don\u0026rsquo;t see what you need, you can enter repositories manually.\nStep 3: Verify Import Once imported, you\u0026rsquo;ll see your project in the dashboard with all its resources—functions, databases, websites, and more.\nTriggering Builds Once imported, you need to trigger builds for each repository.\nScenario 1: Developed on Main Branch If you\u0026rsquo;ve built your project locally using the main branch, push your changes to each repository in this order:\nConfig repo first Code repo second All other repositories (libraries, websites) last This order ensures that configuration is in place before code is built.\nHow to Push Simply push to GitHub:\n# In your config repo git add . git commit -m \u0026#34;Deploy to production\u0026#34; git push origin main # In your code repo git add . git commit -m \u0026#34;Deploy to production\u0026#34; git push origin main # Repeat for other repos Each push triggers a build automatically via GitHub webhooks.\nConclusion You\u0026rsquo;ve learned how to:\nImport your project into production Trigger builds based on your development workflow Verify the deployment Set up continuous deployment With Taubyte, shipping to production is as simple as merging to main. Your cloud handles the rest—building, deploying, and scaling automatically.\n🎉 Congratulations! You\u0026rsquo;ve completed the Taubyte tutorial series! You now know how to:\n✅ Run a local cloud with Dream ✅ Create projects ✅ Build serverless functions ✅ Organize code with libraries ✅ Deploy websites ✅ Use object storage ✅ Work with databases ✅ Implement real-time messaging ✅ Organize with applications ✅ Understand CI/CD ✅ Work with branches ✅ Ship to production For more advanced topics and detailed documentation, visit tau.how and join our Discord community.\nHappy building! 🚀\nReady to deploy your own cloud? Learn how to deploy a Taubyte cloud with SporeDrive on your own infrastructure.\n","permalink":"/blog/posts/ship-to-production-taubyte/","summary":"You\u0026rsquo;ve built your project locally—now it\u0026rsquo;s time to go live. Learn how to import your project into a production Taubyte cloud and trigger builds, whether you\u0026rsquo;ve been developing on main or a feature branch.","title":"Shipping Your Project to Production with Taubyte"},{"content":"When working with projects, the best practice is to create a new branch for each feature or bug fix. This way, you can work in isolation without touching the main branch until your work is ready to merge.\nBoth Tau and Dream support running on branches.\nDefault Behavior By default:\nTau (production) runs on main and master branches Dream (local) also defaults to these branches But you can configure either to run on any branch.\nStarting Dream on a Branch To start Dream on a specific branch, use the -b flag:\ndream new multiverse -b dev This starts a Dream universe that listens for changes on the dev branch instead of main.\nConnecting to Your Branch Universe Once Dream is running on your branch, connect through the web console:\nOpen console.taubyte.com Connect to your Dream universe (should be named blackhole) Either create a new project or import an existing one The Branch Creation Flow Here\u0026rsquo;s a common scenario: you start Dream on a development branch that doesn\u0026rsquo;t exist yet on the remote repository.\nInitial Attempt Trigger a build:\ndream inject push-all You might see an error in Dream logs:\nCheck out \u0026#39;dev\u0026#39; failed with reference not found This happens because the dev branch doesn\u0026rsquo;t exist on the remote repository yet.\nCreating the Branch To fix this, create the branch in the console:\nIn the top right corner, click the current branch name (shows main) Click the + button Type dev as the new branch name Click Validate The console will refresh and show the branch name changed to dev.\nBuilding Successfully Now trigger the build again:\ndream inject push-all This time it should succeed. If you imported a project with existing functions, they\u0026rsquo;ll be built on this branch.\nCommands Reference Command Description dream new multiverse Start Dream on default branch (main) dream new multiverse -b dev Start Dream on dev branch dream inject push-all Trigger builds for all repos Troubleshooting Issue Cause Solution \u0026ldquo;Reference not found\u0026rdquo; Branch doesn\u0026rsquo;t exist on remote Create branch in console Wrong branch building Dream started on different branch Restart Dream with correct -b flag Changes not appearing Built on wrong branch Verify console shows correct branch Best Practices Never develop directly on main: Always use feature branches Name branches descriptively: feature/user-auth, fix/login-bug Test locally first: Use Dream to validate before merging Keep branches short-lived: Merge frequently to avoid conflicts Delete merged branches: Keep your repository clean Conclusion You\u0026rsquo;ve learned how to:\nStart Dream on specific branches with the -b flag Create branches from the console Build and test on feature branches Merge to production when ready Branching enables safe, isolated development that follows industry best practices. You can experiment freely knowing your main branch stays stable until you\u0026rsquo;re ready to merge.\nNext, learn how to ship to production when your project is ready.\n","permalink":"/blog/posts/branches-taubyte/","summary":"Follow best practices for feature development by using Git branches with Taubyte. Learn how to run Dream on development branches, create new branches in the console, and merge changes to production.","title":"Working with Branches in Taubyte"},{"content":"Taubyte comes with a built-in CI/CD system. Every time you push changes to the branch your nodes are running on, a build is triggered automatically.\nNote: When running Dream locally, manual triggering is required since GitHub can\u0026rsquo;t reach your local nodes.\nHow It Works The build process is defined inside the .taubyte folder, which lives at the root of your codebase. You\u0026rsquo;ll find this folder in the code of any function, website, or library.\nFolder Contents File Purpose config.yaml Defines the build workflow build.sh Script executed by the workflow Additional files Build-specific assets The Configuration File The config.yaml file is simple and powerful. It defines:\nEnvironment: Docker image and environment variables Workflow: Steps to run (each step is a shell script) Example config.yaml version: \u0026#34;1.0\u0026#34; environment: image: node:alpine variables: NODE_ENV: production PUBSUB_TOPIC: transactions workflow: - generate.sh - test.sh - build.sh Configuration Breakdown Field Description Example version Config format version \u0026quot;1.0\u0026quot; environment.image Docker image for builds node:alpine environment.variables Environment variables Key-value pairs workflow Ordered list of scripts [\u0026quot;generate.sh\u0026quot;, \u0026quot;test.sh\u0026quot;, \u0026quot;build.sh\u0026quot;] Convention Over Configuration The CI/CD system relies on conventions, not heavy configuration:\nIf all steps succeed, the /out folder is archived and compressed That archive becomes your published asset No complex YAML pipelines or configuration files Building Serverless Functions For serverless functions, Taubyte currently supports WebAssembly only. We provide specialized containers to make this easy.\nOfficial Build Containers Language Container Use Case Go taubyte/go-wasi Go functions Go (libraries) taubyte/go-wasi-lib Go libraries Rust taubyte/rust-wasi Rust functions AssemblyScript taubyte/assemblyscript-wasi AS functions Go Example config.yaml:\nversion: \u0026#34;1.0\u0026#34; environment: image: taubyte/go-wasi workflow: - build.sh build.sh:\n#!/bin/bash go mod tidy tinygo build -o /out/main.wasm -target wasi . Rust Example config.yaml:\nversion: \u0026#34;1.0\u0026#34; environment: image: taubyte/rust-wasi workflow: - build.sh build.sh:\n#!/bin/bash cargo build --release --target wasm32-wasi cp target/wasm32-wasi/release/*.wasm /out/main.wasm Understanding WASI WASI (WebAssembly System Interface) is a standard that extends WebAssembly beyond the browser. It enables Wasm to run safely and efficiently in server, edge, and cloud environments.\nWhat WASI Provides Capability Description File access Read/write files in sandbox Networking HTTP requests, sockets Randomness Cryptographic random numbers Environment Environment variables Clocks Time and timing functions Why WASI Matters for Taubyte WASI modules can interact with the outside world in a controlled, portable way. This means:\nSandboxed execution: Your code runs in isolation Cross-platform: Same binary runs on any node Language agnostic: Go, Rust, or AssemblyScript compile to the same target Consistent behavior: No platform-specific surprises Output Requirements For Functions Your build must output a file at:\n/out/main.wasm This is the WebAssembly binary that gets deployed.\nFor Websites All files must be placed in:\n/out/ The entire folder contents become your static site.\nWebsite Example config.yaml:\nversion: \u0026#34;1.0\u0026#34; environment: image: node:18-alpine variables: NODE_ENV: production workflow: - build.sh build.sh (for a React app):\n#!/bin/bash npm install npm run build mkdir -p /out cp -r build/* /out/ Triggering Builds In Production Builds trigger automatically when you push to GitHub (via webhook).\nIn Dream Manually trigger builds:\n# Build all repositories dream inject push-all # Build specific repository dream inject push-specific \u0026lt;repo-id\u0026gt; Tips for Faster Builds Use Alpine images: Smaller images download faster Cache dependencies: Some containers cache npm/go modules Minimize assets: Smaller outputs deploy faster Use libraries: Compile shared code once, use everywhere Common Build Issues Issue Cause Solution /out/main.wasm not found Build output in wrong location Check build.sh output path Docker image not found Typo in image name Verify container name Build timeout Long compilation Optimize code, split into libraries Missing dependencies Not in container Add npm install or go mod tidy Conclusion Taubyte\u0026rsquo;s CI/CD system is designed for simplicity:\nConvention-based: Minimal configuration required WebAssembly-first: Portable, secure, fast Automatic deploys: Push to GitHub, get deployed Built-in containers: No need to manage build infrastructure Every push builds and publishes your serverless functions and static websites automatically, keeping deployment simple and seamless.\nNext, learn about working with branches for feature development and testing.\n","permalink":"/blog/posts/cicd-taubyte/","summary":"Taubyte includes a built-in CI/CD system that automatically builds and deploys your code when you push to GitHub. Learn how it works, how to configure builds, and how serverless functions compile to WebAssembly.","title":"Understanding Taubyte's Built-in CI/CD System"},{"content":"In Taubyte, resources can have either global scope—accessible from anywhere in your project—or application scope—contained within a specific application. Applications let you group resources under logical units for better organization, granular access control, and clearer project structure as your system grows.\nWhat Are Applications? Applications are organizational containers within your Taubyte project. Each application:\nHas access to its own resources plus any global resources Provides logical separation between different parts of your system Enables granular access control and management Can have unique settings for databases, functions, and more Example Use Cases Application Purpose backend API services and business logic admin Admin dashboard and management functions public-api Customer-facing API endpoints analytics Data processing and reporting Creating an Application From the sidebar, navigate to Applications and click the + button.\nFill in the details:\nField Description Example Name Application identifier backend Description What this application does Backend API services Click Validate to save.\nYour application will now appear in the list.\nPushing Changes Changes are saved locally in your browser\u0026rsquo;s virtual file system. To persist them:\nClick the green button in the bottom right corner Enter a commit message Click Finish Tip: You don\u0026rsquo;t need to push immediately. Continue working and push when you\u0026rsquo;re ready.\nAdding Resources to an Application Click on the application\u0026rsquo;s name to open it.\nInside an application, you can define the same types of resources you would globally:\nFunctions Databases Websites Storage Messaging Creating an Application-Scoped Function Go to the Functions tab within your application Click the + button Select the ping_pong template Set the domain to your generated domain Set the path to /backend/ping Note: The path doesn\u0026rsquo;t need to include the application name—you can use any path.\nSwitch to the Code tab and customize:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; ) //export ping func ping(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } h.Write([]byte(\u0026#34;PONG from backend application!\u0026#34;)) return 0 Click Validate to save.\nPushing and Building Push your code—the new function will appear with a \u0026ldquo;1+ change\u0026rdquo; indicator.\nAdd a commit message and click Finish.\nIf using Dream locally, trigger a build:\ndream inject push-all Testing Once the build finishes, click the lightning icon to open the function\u0026rsquo;s HTTP endpoint.\nIf it doesn\u0026rsquo;t open, ensure your generated domain is in your /etc/hosts file.\nThe function should return:\nPONG from backend application! Resource Visibility Here\u0026rsquo;s how resource visibility works with applications:\n┌─────────────────────────────────────────────────────────────┐ │ PROJECT │ ├─────────────────────────────────────────────────────────────┤ │ GLOBAL RESOURCES │ │ ├── shared_database │ │ ├── common_functions │ │ └── main_website │ ├─────────────────────────────────────────────────────────────┤ │ APPLICATION: backend │ │ ├── Can access: ALL global resources │ │ ├── backend_database (application-scoped) │ │ └── api_functions (application-scoped) │ ├─────────────────────────────────────────────────────────────┤ │ APPLICATION: admin │ │ ├── Can access: ALL global resources │ │ ├── admin_database (application-scoped) │ │ └── admin_functions (application-scoped) │ └─────────────────────────────────────────────────────────────┘ Key points:\nApplications can access global resources Applications cannot access other applications\u0026rsquo; resources Global resources are shared across all applications Benefits of Using Applications Benefit Description Organization Group related resources logically Access Control Isolate sensitive resources Team Collaboration Different teams can own different applications Maintainability Easier to navigate large projects Scalability Add applications as your project grows When to Use Applications Scenario Recommendation Simple project (\u0026lt;10 resources) Global resources only Multiple API domains Separate applications Different access requirements Applications for isolation Microservices architecture One application per service Team boundaries One application per team Conclusion You\u0026rsquo;ve learned how to:\nCreate applications to organize resources Add functions within applications Understand visibility between global and application-scoped resources Applications provide a clean way to structure your project as it grows, enabling better organization and access control without sacrificing the ability to share common resources.\nNext, learn about the CI/CD system that builds and deploys your code automatically.\n","permalink":"/blog/posts/taubyte-applications/","summary":"Applications in Taubyte let you group resources under logical units for better organization and access control. Learn how to create applications and scope resources to them while maintaining access to global resources.","title":"Organizing Resources with Taubyte Applications"},{"content":"Taubyte includes built-in pub/sub messaging that enables real-time communication in your applications. With WebSocket support, you can build chat systems, live notifications, collaborative tools, and more—all directly from your serverless functions.\nCreating a Messaging Channel From the sidebar, navigate to Messaging and click the + button.\nConfigure your channel:\nField Description Example Name Channel identifier chat_channel Topic Matcher Topic pattern chat/rooms WebSocket Enable WebSocket support ✅ Toggle on Click Validate to save.\nPushing Changes Click the green push button, review your changes, add a commit message, and push to the repository.\nBuild and deploy:\ndream inject push-all Connecting Pub/Sub to Functions Now let\u0026rsquo;s create a function that provides WebSocket URLs for clients to connect.\nCreate the WebSocket URL Function Navigate to Functions and click +:\nClick Template Select Choose Go and get WebSocket URL Set the domain to your generated domain Set the path to /api/ws Switch to the Code tab and replace with:\npackage lib import ( \u0026#34;crypto/sha256\u0026#34; \u0026#34;encoding/hex\u0026#34; \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;github.com/taubyte/go-sdk/pubsub\u0026#34; ) //export getWebSocketURL func getWebSocketURL(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } // Get room name from query parameters query := h.Query() room := query.Get(\u0026#34;room\u0026#34;) if room == \u0026#34;\u0026#34; { h.Write([]byte(`{\u0026#34;error\u0026#34;: \u0026#34;room parameter required\u0026#34;}`)) return 1 } // Hash the room name to create a unique channel hash := sha256.Sum256([]byte(room)) channelName := hex.EncodeToString(hash[:]) // Open or create the pub/sub channel channel, err := pubsub.Open(\u0026#34;chat/rooms/\u0026#34; + channelName) if err != nil { h.Write([]byte(`{\u0026#34;error\u0026#34;: \u0026#34;failed to open channel\u0026#34;}`)) return 1 } defer channel.Close() // Get WebSocket URL for this channel wsURL, err := channel.WebSocketURL() if err != nil { h.Write([]byte(`{\u0026#34;error\u0026#34;: \u0026#34;failed to get websocket url\u0026#34;}`)) return 1 } h.Write([]byte(wsURL)) return 0 } This function:\nReads the room query parameter Hashes it to create a unique channel name Opens (or creates) the pub/sub channel Returns a WebSocket URL for clients to connect Validate and push, then trigger a build:\ndream inject push-all Testing with wscat Install wscat First, install the WebSocket testing tool:\nnpm install -g wscat Get a WebSocket URL Request a WebSocket URL for a room:\ncurl \u0026#34;http://your-domain.blackhole.localtau:14529/api/ws?room=tau\u0026#34; Response (example):\n/ws/channel/a8f5f167f44f4964e6c998dee827110c... Connect Two Clients Open two terminal windows to simulate a chat:\nTerminal 1:\nwscat -c \u0026#34;ws://your-domain.blackhole.localtau:14529/ws/channel/a8f5f167f44f4964e6c998dee827110c...\u0026#34; Terminal 2:\nwscat -c \u0026#34;ws://your-domain.blackhole.localtau:14529/ws/channel/a8f5f167f44f4964e6c998dee827110c...\u0026#34; Now type in one terminal—it appears instantly in the other!\nYour pub/sub WebSocket is alive.\nUse Cases Use Case Implementation Chat rooms Per-room channels with WebSocket Live notifications Global channel, functions publish Real-time dashboards Data channels, subscribe from frontend Collaborative editing Document-specific channels Game state sync Game room channels Conclusion You\u0026rsquo;ve learned how to:\nCreate messaging channels with WebSocket support Build functions that return WebSocket URLs Test with wscat for real-time communication Build browser clients for chat applications Pub/sub is the foundation for real-time features in your applications—from chat to live notifications to collaborative tools.\nNext, learn about Applications for organizing resources into logical units.\n","permalink":"/blog/posts/messaging-pubsub-taubyte/","summary":"Build real-time features with Taubyte\u0026rsquo;s built-in pub/sub messaging. Create WebSocket-enabled channels for chat, notifications, live updates, and more—all from your serverless functions.","title":"Real-Time Messaging with Pub/Sub in Taubyte"},{"content":"Taubyte provides key-value databases that you can access directly from your serverless functions. Like storage, databases are instantiated on-the-fly when first used—enabling dynamic, multi-tenant data isolation without manually creating each database instance.\nCreating a Database From the sidebar, navigate to Databases and click the + button.\nConfigure your database:\nField Description Example Name Unique identifier example_kv_store Matcher Path pattern /example/kv Min Replication Minimum copies 1 Max Replication Maximum copies 2 Size Maximum capacity 100MB Click Validate to save.\nUnderstanding Matchers Just like storage, the matcher can be any string or regular expression. Using a path-like format (e.g., /example/kv) keeps things organized and readable.\nNote: This configuration only exists locally in your browser\u0026rsquo;s virtual file system. Click the green button to push it to GitHub.\nHow Databases Work Taubyte databases are instantiated on-the-fly the first time you use them. This enables powerful patterns:\nStatic matcher:\n/example/kv Dynamic matcher (regex):\nprofile/history/[a-zA-Z0-9]+ With the regex matcher:\nprofile/history/userA → Creates a database for User A profile/history/userB → Creates a separate database for User B This is incredibly useful for multi-user applications—you can isolate data per user without manually creating each database.\nBuilding Database Functions Let\u0026rsquo;s create two functions to interact with our database:\nKV Set: Store a key-value pair KV Get: Retrieve a value by key Set Function Navigate to Functions and click +:\nField Value Name kv_set Memory 10MB Method POST Path /api/kv Entry Point set Switch to the Code tab and paste:\npackage lib import ( \u0026#34;encoding/json\u0026#34; \u0026#34;github.com/taubyte/go-sdk/database\u0026#34; \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; http \u0026#34;github.com/taubyte/go-sdk/http/event\u0026#34; ) func fail(h http.Event, err error, code int) uint32 { h.Write([]byte(err.Error())) h.Return(code) return 1 } type Req struct { Key string `json:\u0026#34;key\u0026#34;` Value string `json:\u0026#34;value\u0026#34;` } //export set func set(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } // (Create) \u0026amp; Open the database db, err := database.New(\u0026#34;/example/kv\u0026#34;) if err != nil { return fail(h, err, 500) } // Decode the request body reqDec := json.NewDecoder(h.Body()) defer h.Body().Close() // Decode the request body var req Req err = reqDec.Decode(\u0026amp;req) if err != nil { return fail(h, err, 500) } // Put the key/value into the database err = db.Put(req.Key, []byte(req.Value)) if err != nil { return fail(h, err, 500) } return 0 } Validate and push the function.\nGet Function Clone the kv_set function and modify:\nField Value Name kv_get Method GET Entry Point get Update the code:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/database\u0026#34; \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; http \u0026#34;github.com/taubyte/go-sdk/http/event\u0026#34; ) func fail(h http.Event, err error, code int) uint32 { h.Write([]byte(err.Error())) h.Return(code) return 1 } //export get func get(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } key, err := h.Query().Get(\u0026#34;key\u0026#34;) if err != nil { return fail(h, err, 400) } db, err := database.New(\u0026#34;/example/kv\u0026#34;) if err != nil { return fail(h, err, 500) } value, err := db.Get(key) if err != nil { return fail(h, err, 500) } h.Write(value) h.Return(200) return 0 } Validate and push.\nBuilding and Testing Trigger the build:\ndream inject push-all Test Set Once the build is done, you can test the function by sending a POST request to the endpoint:\ncurl -X POST http://your-domain.blackhole.localtau:14529/api/kv -H \u0026#34;Content-Type: application/json\u0026#34; -d \u0026#39;{ \u0026#34;key\u0026#34;: \u0026#34;message\u0026#34;, \u0026#34;value\u0026#34;: \u0026#34;hello world!\u0026#34; }\u0026#39; Note: Replace your-domain.blackhole.localtau with your own domain and 14529 with your own port.\nUnless the curl fails, we now have a key message that contains hello world! in our database.\nTest Get Wait for the build to finish, then test the function by sending a GET request to the endpoint:\ncurl http://your-domain.blackhole.localtau:14529/api/kv?key=message Output:\nhello world! Database Operations Operation Method Description Open(path) - Open or create a database Put(key, value) - Store a key-value pair Get(key) - Retrieve value by key Delete(key) - Remove a key-value pair List(prefix) - List keys with prefix Close() - Close database connection Replication The replication settings control data durability:\nSetting Description Min Replication Minimum copies across nodes Max Replication Maximum copies for redundancy Higher replication = more durability, more storage used.\nConclusion You\u0026rsquo;ve learned how to:\nCreate databases with configurable replication Build set/get functions for key-value operations Use dynamic matchers for per-user data isolation Taubyte\u0026rsquo;s on-the-fly database creation eliminates the need to pre-provision databases, making it perfect for dynamic, multi-tenant applications.\nNext, explore Messaging with Pub/Sub for real-time communication.\n","permalink":"/blog/posts/taubyte-databases/","summary":"Add structured data storage to your Taubyte applications with key-value databases. Like storage, databases are created on-the-fly when first used—enabling dynamic, multi-tenant data isolation without extra configuration.","title":"Key-Value Databases in Taubyte"},{"content":"Taubyte\u0026rsquo;s object storage lets you store and retrieve files directly from your serverless functions. Unlike traditional cloud storage providers where you must pre-provision buckets, Taubyte creates storage buckets on-the-fly when your code first uses them—making it perfect for dynamic, multi-user applications.\nCreating Storage From the sidebar, navigate to Storage and click the + button.\nConfigure your storage:\nField Description Example Name Unique identifier simple_storage Matcher Path pattern for the bucket /simple/storage Type Storage type Object Bucket Size Maximum capacity 1GB Click Validate to save.\nUnderstanding Matchers The matcher can be any string—even a regular expression. Using a path-like format (e.g., /simple/storage) makes it easy to recognize and organize.\nRegular expression example:\nprofile/storage/[a-zA-Z0-9]+ This means:\nprofile/storage/userA → Creates a bucket for User A profile/storage/userB → Creates a separate bucket for User B This is incredibly powerful for multi-user applications—you can automatically generate per-user or per-session buckets just by varying the path.\nPushing Configuration Click the push button, add a commit message, and push to save your storage configuration.\nHow Taubyte Storage Works Unlike major cloud providers where you pre-provision storage, Taubyte storage is instantiated on-the-fly the first time you use it.\nThis means:\nThe bucket doesn\u0026rsquo;t exist until your code interacts with it You can use dynamic matchers (regular expressions) Per-user buckets are created automatically As of today, storage is only accessible from your code. To interact with it over HTTP, you need to create gateway functions.\nBuilding Gateway Functions Let\u0026rsquo;s create two functions:\nUpload function: Store files in a bucket Download function: Retrieve files from a bucket Upload Function Navigate to Functions and click +:\nField Value Name store_file Memory 100MB Method POST Path /api/store Entry Point store Switch to the Code tab and paste:\npackage lib import ( \u0026#34;encoding/json\u0026#34; \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; http \u0026#34;github.com/taubyte/go-sdk/http/event\u0026#34; \u0026#34;github.com/taubyte/go-sdk/storage\u0026#34; ) func failed(h http.Event, err error, code int) uint32 { h.Write([]byte(err.Error())) h.Return(code) return 1 } type Req struct { Filename string `json:\u0026#34;filename\u0026#34;` Data string `json:\u0026#34;data\u0026#34;` } //export store func store(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } // Open/Create the storage sto, err := storage.New(\u0026#34;/simple/storage\u0026#34;) if err != nil { return failed(h, err, 500) } // Read the request body reqDec := json.NewDecoder(h.Body()) defer h.Body().Close() var req Req err = reqDec.Decode(\u0026amp;req) if err != nil { return failed(h, err, 500) } // Select file/object file := sto.File(req.Filename) // Write data to the file _, err = file.Add([]byte(req.Data), true) if err != nil { return failed(h, err, 500) } return 0 } Download Function Clone the store_file function and modify:\nField Value Name get_file Method GET Path /api/get Entry Point get Update the code:\npackage lib import ( \u0026#34;io\u0026#34; \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; http \u0026#34;github.com/taubyte/go-sdk/http/event\u0026#34; \u0026#34;github.com/taubyte/go-sdk/storage\u0026#34; ) func failed(h http.Event, err error, code int) uint32 { h.Write([]byte(err.Error())) h.Return(code) return 1 } //export get func get(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } // Read the filename from the query string filename, err := h.Query().Get(\u0026#34;filename\u0026#34;) if err != nil { return failed(h, err, 400) } // Open/Create the storage sto, err := storage.New(\u0026#34;/simple/storage\u0026#34;) if err != nil { return failed(h, err, 500) } // Select file/object file := sto.File(filename) // Get a io.ReadCloser reader, err := file.GetFile() if err != nil { return failed(h, err, 500) } defer reader.Close() // Read from file and write to response _, err = io.Copy(h, reader) if err != nil { return failed(h, err, 500) } return 0 } Building and Testing Trigger the build:\ndream inject push-all Test Upload curl -I -X POST http://your-domain.blackhole.localtau:14529/api/store \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{ \u0026#34;filename\u0026#34;: \u0026#34;example.txt\u0026#34;, \u0026#34;data\u0026#34;: \u0026#34;This is the content of the file.\u0026#34; }\u0026#39; Unless the curl fails, we now have an object example.txt that contains This is the content of the file. in our storage.\nTest Download curl http://your-domain.blackhole.localtau:14529/api/get?filename=example.txt The output should be:\nThis is the content of the file. Storage Patterns Use Case Matcher Pattern Single shared bucket app/files Per-user buckets users/storage/.* Per-session storage sessions/[0-9a-f]{8} Per-project files projects/.+/assets Conclusion You\u0026rsquo;ve learned how to:\nCreate storage with matchers Build upload/download functions as HTTP gateways Use dynamic matchers for per-user storage Taubyte\u0026rsquo;s on-the-fly bucket creation eliminates the need to pre-provision storage, making it perfect for applications with dynamic, multi-tenant requirements.\nNext, explore Databases for structured data storage.\n","permalink":"/blog/posts/object-storage-taubyte/","summary":"Learn how to add object storage to your Taubyte application. Unlike traditional cloud storage, Taubyte creates buckets on-the-fly when you first use them—perfect for dynamic, multi-user applications.","title":"Object Storage in Taubyte"},{"content":"Taubyte makes hosting static websites straightforward. Whether you\u0026rsquo;re building a simple landing page, a single-page application, or a full-featured web app, you can deploy and serve your website directly on your Taubyte cloud with automatic builds and instant previews.\nCreating a Website From the sidebar, navigate to Websites and click the + button.\nConfigure your website:\nField Description Example Name Unique identifier my-website Repository Generate new or import existing Generate Private Repository visibility Toggle on for private Domain Which domain to serve on GeneratedDomain Path URL path / Choosing a Template Taubyte offers several templates to get you started:\nHTML: Basic HTML/CSS/JS starter React: React application boilerplate Vue: Vue.js starter template Static: Empty static site Select your preferred template and click Generate.\nThis instantly creates a fresh GitHub repository with starter code ready for customization.\nPushing Configuration Click the push button in the bottom right to save your configuration.\nBefore finalizing:\nOpen the websites folder Find the YAML file for your website Copy the ID and GitHub repo name—you\u0026rsquo;ll need these for builds Type a commit message and push.\nEditing Your Website Click the open in browser icon next to your website in the list. This takes you directly to the GitHub repository.\nMaking Changes Open index.html (or your main file) Click Edit Make your changes: \u0026lt;!DOCTYPE html\u0026gt; \u0026lt;html lang=\u0026#34;en\u0026#34;\u0026gt; \u0026lt;head\u0026gt; \u0026lt;meta charset=\u0026#34;UTF-8\u0026#34; /\u0026gt; \u0026lt;meta name=\u0026#34;viewport\u0026#34; content=\u0026#34;width=device-width, initial-scale=1.0\u0026#34; /\u0026gt; \u0026lt;title\u0026gt;My Taubyte Site\u0026lt;/title\u0026gt; \u0026lt;style\u0026gt; body { font-family: -apple-system, BlinkMacSystemFont, \u0026#34;Segoe UI\u0026#34;, Roboto, sans-serif; max-width: 800px; margin: 50px auto; padding: 20px; background: linear-gradient(135deg, #667eea 0%, #764ba2 100%); min-height: 100vh; color: white; } h1 { font-size: 3rem; } \u0026lt;/style\u0026gt; \u0026lt;/head\u0026gt; \u0026lt;body\u0026gt; \u0026lt;h1\u0026gt;Welcome to My Taubyte Site!\u0026lt;/h1\u0026gt; \u0026lt;p\u0026gt;This site is hosted on my own cloud infrastructure.\u0026lt;/p\u0026gt; \u0026lt;/body\u0026gt; \u0026lt;/html\u0026gt; Commit the changes Triggering a Build Since Dream doesn\u0026rsquo;t automatically trigger builds from GitHub, do it manually:\n# Use the ID and full repo name you copied earlier dream inject push-specific --rid \u0026lt;github-id\u0026gt; --fn \u0026lt;repo-name\u0026gt; Navigate to the Builds page in the console and wait for completion.\nViewing Your Website Local Setup Required Before previewing, add your generated domain to /etc/hosts:\nsudo nano /etc/hosts Add:\n127.0.0.1 your-domain.blackhole.localtau Open the Website Back in the console:\nNavigate to Websites Click the lightning icon next to your website A new tab opens with your live site! Website Structure Generated websites follow this structure:\nmy-website/ ├── index.html # Main entry point ├── css/ │ └── style.css # Stylesheets ├── js/ │ └── app.js # JavaScript ├── assets/ │ └── images/ # Static assets └── .taubyte/ ├── config.yaml # Build configuration └── build.sh # Build script The .taubyte Folder This folder is essential for proper deployment:\nconfig.yaml - Defines the build environment:\nversion: \u0026#34;1.0\u0026#34; environment: image: node:alpine variables: NODE_ENV: production workflow: - build.sh build.sh - The build script:\n#!/bin/bash mkdir -p /out cp -r * /out/ rm -rf /out/.taubyte Important: All output must go to the /out folder.\nAdvanced: Building with Frameworks For frameworks like React or Vue, the build process is more involved:\nReact Example config.yaml:\nversion: \u0026#34;1.0\u0026#34; environment: image: node:18-alpine variables: NODE_ENV: production workflow: - build.sh build.sh:\n#!/bin/bash npm install npm run build mkdir -p /out cp -r build/* /out/ Vue Example build.sh:\n#!/bin/bash npm install npm run build mkdir -p /out cp -r dist/* /out/ Troubleshooting Issue Solution Website not loading Check /etc/hosts includes your domain Build failed Review build logs in the Builds tab 404 errors Ensure index.html exists at root Assets not loading Verify paths are relative, not absolute Conclusion You\u0026rsquo;ve just created and deployed your first website on Taubyte:\nCreated a website with a template Edited the HTML in GitHub Triggered a build Previewed your live site With websites and functions sharing the same domain, you can build complete web applications with seamless frontend-backend integration.\nNext, learn about Object Storage for storing and serving files.\n","permalink":"/blog/posts/hosting-websites-taubyte/","summary":"Taubyte makes hosting static websites simple. Learn how to create, configure, and deploy a website on your Taubyte cloud with automatic builds and instant previews.","title":"Hosting Websites on Taubyte"},{"content":"When building serverless functions in Taubyte, you have two options for organizing your code: inline code within your project, or libraries—separate repositories that can be shared and reused across functions and projects.\nLibraries in Taubyte enable you to:\nKeep serverless function code outside the main repository Share code across multiple functions Control access more precisely with separate repositories Build reusable components for your entire platform Prerequisites Before you begin, make sure you have:\nA local Taubyte cloud running with Dream:\nInstall Dream: npm install -g @taubyte/dream Start your local cloud: dream new multiverse Connect to it at console.taubyte.com by selecting the blackhole network A Taubyte project created in the console (if you haven\u0026rsquo;t created one yet, see Creating Your First Taubyte Project)\nCreating a Library From the sidebar, navigate to Libraries and click the + button.\nName your library (e.g., my-shared-lib) Choose to either: Import an existing library using its repository URL Generate a new repository with starter code Click Generate to create a new library This creates a GitHub repository with template code.\nPushing Changes Click the green button in the bottom right to push:\nImportant: Copy and save the Library GitHub ID—you\u0026rsquo;ll need it for builds Enter a commit message Click Finish Skip the build for now (the library isn\u0026rsquo;t in use yet) Adding Code to Your Library Click the open icon to view your library\u0026rsquo;s repository on GitHub.\nOpen the template file (e.g., empty.go) and replace its content:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; ) //export ping func ping(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } h.Write([]byte(\u0026#34;PONG\u0026#34;)) return 0 Commit the changes directly on GitHub.\nUsing a Library as a Function Source Now let\u0026rsquo;s create a function that uses this library as its code source.\nNavigate to Functions and click +:\nField Value Name Your function name Timeout 1s Memory 10MB Method GET Domain GeneratedDomain Path /lib/ping Source Select your library (e.g., my-shared-lib) Entry Point ping Push the changes, ignore any inline code repo updates, commit and finish. Notice the source is now your library.\nBuilding the Library In your terminal, build both the library and configuration:\n# Build the specific library using its ID and fullname dream inject push-specific -u blackhole -rid \u0026lt;library-github-id\u0026gt; -fn \u0026lt;library-fullname\u0026gt; # Build all configuration dream inject push-all Note: Use your own repository ID and fullname. If you didn\u0026rsquo;t save them, navigate to the library, click on it, then switch to YAML to find them. Another way is to open the config repository and find them in libraries/\u0026lt;library-name\u0026gt;.yaml.\nTesting Once both builds finish, go back to the console, click the lightning icon next to your function. You should see the PONG message.\nUsing a Library as a Dependency Libraries can also be imported as dependencies within other functions. This is powerful for creating reusable utility modules.\nStep 1: Add a Utility Function to Your Library In your library repository, click Add file \u0026gt; Create new file. Name the file add.go and add the following code:\npackage lib //export add func add(a, b uint32) uint64 { return uint64(a) + uint64(b) } Click Commit changes\u0026hellip; to commit and push.\nStep 2: Create a Function that Imports the Library Navigate to Functions and click +. Click Template Select, select Go and empty, then close the template modal.\nConfigure the function:\nField Value Name add Timeout 1s Memory 10MB Method GET Domain GeneratedDomain Path /lib/add Entry Point doAdd Click on Code to switch to the code tab, then paste the following code:\npackage lib import ( \u0026#34;fmt\u0026#34; \u0026#34;strconv\u0026#34; \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; http \u0026#34;github.com/taubyte/go-sdk/http/event\u0026#34; ) // Import `add` the library // //go:wasmimport libraries/\u0026lt;library-name\u0026gt; add func add(a, b uint32) uint64 func getQueryVarAsUint32(h http.Event, varName string) uint32 { varStr, err := h.Query().Get(varName) if err != nil { panic(err) } varUint, err := strconv.ParseUint(varStr, 10, 32) if err != nil { panic(err) } return uint32(varUint) } //export doAdd func doAdd(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } // call the library function sum := add(getQueryVarAsUint32(h, \u0026#34;a\u0026#34;), getQueryVarAsUint32(h, \u0026#34;b\u0026#34;)) // send the result over http h.Write([]byte(fmt.Sprintf(\u0026#34;%d\u0026#34;, sum))) return 0 } Note: libraries/\u0026lt;library-name\u0026gt; is resolved within the context of the application the function is part of, then globally. In this case the function is global so the library is only resolved globally.\nPush the changes.\nStep 3: Build and Test Trigger a build for the configuration changes:\ndream inject push-all Test the function with curl:\ncurl \u0026#39;http://your-domain.blackhole.localtau:14529/lib/add?a=40\u0026amp;b=2\u0026#39; Output:\n42 Library vs. Inline Code: When to Use Each Use Case Recommendation Quick prototypes Inline code Shared utilities Library Multiple functions same logic Library Strict access control Library (separate repo) Complex applications Library Simple HTTP handlers Either works Conclusion You\u0026rsquo;ve now learned how to:\nCreate libraries for code organization Use libraries as function sources for cleaner architecture Import libraries as dependencies for code reuse Libraries are a powerful way to keep your codebase organized as your project grows. They enable sharing logic across your entire platform while maintaining clear ownership and access control.\nNext, learn how to host websites on your Taubyte cloud.\n","permalink":"/blog/posts/taubyte-libraries/","summary":"Libraries in Taubyte let you keep serverless function code in separate repositories, share logic across multiple functions, and control access more precisely. Learn how to create libraries and use them both as function sources and as imported dependencies.","title":"Code Reuse with Taubyte Libraries"},{"content":"Serverless functions are the building blocks of modern cloud applications. In Taubyte, functions are compiled to WebAssembly and executed in a lightweight, secure sandbox. Let\u0026rsquo;s build one from scratch.\nCreating a Function From your project dashboard, navigate to Functions in the sidebar and click the + button.\nYou have two options for creating a function:\nOption 1: Start from Scratch Fill in the function details manually:\nField Description Example Name Unique identifier ping_pong Protocol Trigger type HTTPS Description What the function does Returns pong to a ping Tags Optional labels demo, http Timeout Maximum execution time 10s Memory Allocated memory 10MB Method HTTP method GET Domain Which domain to use GeneratedDomain Path URL path trigger /ping Source Code location . (inline) or library name Entry Point Function name in code ping Option 2: Use a Template (Recommended) Templates accelerate development by providing working examples:\nClick Template Select Choose a language (Go, Rust, or AssemblyScript) Select a template (e.g., ping_pong) The template fills in most fields automatically Select your domain from the dropdown Understanding the Configuration Click the YAML tab to see the configuration in raw format:\nid: \u0026#34;\u0026#34; description: Returns pong to a ping over HTTP tags: [] source: . trigger: type: https method: GET paths: - /ping domains: - GeneratedDomain execution: timeout: 10s memory: 10MB call: ping Key fields:\nsource: Use . for inline code or a library name for external code execution.call: The function name that must be exported by your WebAssembly module Tip: You can also upload a YAML configuration file by clicking the upload button in the bottom left.\nWriting the Code Switch to the Code tab to view and edit your function\u0026rsquo;s source code.\nHere\u0026rsquo;s a simple Go ping-pong function:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; ) //export ping func ping(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } h.Write([]byte(\u0026#34;PONG\u0026#34;)) return 0 } Code Guidelines Package name: Use any name except main—it\u0026rsquo;s reserved for the build container Taubyte SDK: Use github.com/taubyte/go-sdk for fast, low-memory operations Function export: Annotate with //export functionName (TinyGo requirement) Event system: Functions receive an event.Event for lightweight execution The .taubyte folder: Contains build configurations—essential for proper execution Pushing Your Changes Click Done when your function is ready, then:\nClick the green button in the bottom right to push changes Open the domains folder and find GeneratedDomain.yaml Copy the domain FQDN—you\u0026rsquo;ll need it for testing Enter a commit message Push to GitHub Triggering Builds In Production Pushing to GitHub automatically triggers a build via webhooks.\nIn Dream (Local Development) GitHub can\u0026rsquo;t access your local nodes, so trigger builds manually:\nTerminal method:\ndream inject push-all Console method:\nGo to console.taubyte.com Click Dreamland in the sidebar Select Network → blackhole From the top-right menu, choose Push All Monitoring Builds Navigate to Builds in the sidebar. You\u0026rsquo;ll see jobs for:\nConfiguration build: Quick, processes YAML files Code build: Compiles your function to WebAssembly Click the stack icon next to a completed build to view function logs.\nTesting Your Function Find Your HTTP Port First, get the substrate HTTP port:\ndream status substrate Output:\n┌─────────────────────┬────────┬───────┐ │ substrate@blackhole │ http │ 14529 │ └─────────────────────┴────────┴───────┘ Test with cURL Using the host header:\ncurl -H \u0026#34;Host: your-domain.blackhole.localtau\u0026#34; http://127.0.0.1:14529/ping Output:\nPONG Simplify Local Testing Add your generated domain to /etc/hosts for easier testing:\nsudo nano /etc/hosts Add this line:\n127.0.0.1 your-domain.blackhole.localtau Now you can test without the Host header:\ncurl http://your-domain.blackhole.localtau:14529/ping Test via Console Navigate to Functions in the sidebar Find your function in the list Click the lightning icon to open it in a new tab Troubleshooting Issue Solution Function not responding Verify port matches dream status substrate output Build failed Check the Builds tab for error messages Changes not appearing Run dream inject push-all again \u0026ldquo;PONG\u0026rdquo; not returning Ensure entry point matches the exported function name Conclusion You\u0026rsquo;ve now learned how to create, configure, and deploy serverless functions in Taubyte. The process is straightforward:\nCreate the function (manually or from a template) Write your code in Go, Rust, or AssemblyScript Push to GitHub Trigger a build (automatic in production, manual in Dream) Test your function Functions compile to WebAssembly for secure, fast, and portable execution across your entire cloud infrastructure.\nNext, explore Libraries to learn how to share code across multiple functions.\n","permalink":"/blog/posts/serverless-functions-taubyte/","summary":"Learn how to create, configure, and deploy serverless functions in Taubyte. This hands-on guide walks through building a simple ping-pong function in Go, from creation to testing both locally and in production.","title":"Building Serverless Functions in Taubyte"},{"content":"Getting started with Taubyte begins with creating a project. In this guide, we\u0026rsquo;ll walk through the process using the web console—a method that works identically whether you\u0026rsquo;re testing locally with Dream or setting up for production.\nAccessing the Console Open your browser and navigate to console.taubyte.com.\nYou\u0026rsquo;ll be greeted with a login screen where you need to:\nEnter your email address Choose your network: Select Dreamland/blackhole for local development Enter your custom domain for production deployments Click \u0026ldquo;Login with GitHub\u0026rdquo; The console will request permission to access your GitHub account. This is necessary so it can:\nCreate repositories for your project Push configuration and code changes Trigger CI/CD builds Important: Your GitHub token is stored only in your browser—it never leaves your machine.\nCreating a Project Once logged in, you\u0026rsquo;ll see the projects dashboard. To create a new project:\nClick the Create Project button\nFill out the short form:\nProject Name: A unique identifier for your project Description: Brief explanation of what you\u0026rsquo;re building Visibility: Choose between private or public repositories Click Create Project\nThat\u0026rsquo;s all there is to the setup!\nWhat Gets Created When you create a project, Taubyte automatically creates two GitHub repositories:\nRepository Purpose Contents Config Repo Project settings YAML files for functions, databases, domains, etc. Code Repo Inline code Source code in your chosen language (Go, Rust, AssemblyScript) This separation allows you to:\nManage configuration separately from code Have clear version history for infrastructure changes Use Git workflows you\u0026rsquo;re already familiar with Repository Structure Config Repository:\nyour-project-config/ ├── domains/ │ └── generated-domain.yaml ├── functions/ │ └── my-function.yaml └── databases/ └── my-database.yaml Code Repository:\nyour-project-code/ ├── functions/ │ └── my-function/ │ └── .taubyte/ │ ├── config.yaml │ └── build.sh └── websites/ └── my-website/ └── index.html After Creation Once your project is created, you\u0026rsquo;ll be taken directly to your new project\u0026rsquo;s dashboard. From here, you can:\nCreate functions for serverless computing Set up databases for structured data storage Deploy websites for static hosting Configure storage for object storage Set up messaging for pub/sub patterns Development vs. Production The beauty of Taubyte\u0026rsquo;s approach is that the steps are identical regardless of your environment:\nAction Dream (Local) Production Create project ✅ Same process ✅ Same process Add functions ✅ Same process ✅ Same process Configure databases ✅ Same process ✅ Same process Push changes dream inject push-all Automatic via GitHub webhooks The only difference is how builds are triggered:\nIn Dream: You manually trigger with dream inject push-all In Production: GitHub webhooks automatically trigger builds Next Steps With your project created, you\u0026rsquo;re ready to:\nCreate Functions - Deploy serverless code Set Up Libraries - Share code across functions Deploy Websites - Host static sites Conclusion Creating a Taubyte project is straightforward—fill out a simple form and let the platform handle repository creation and configuration. The Git-based approach means you always have a clear audit trail and can use familiar development workflows.\nThe fact that local and production processes are identical ensures that what works in development will work in production, eliminating deployment surprises.\nFor detailed documentation on all project features, visit tau.how.\nNext: Build your first serverless function to start deploying code.\n","permalink":"/blog/posts/creating-your-first-taubyte-project/","summary":"Learn how to create a Taubyte project using the web console. This guide covers the process for both local development with Dream and production deployments, showing you how Taubyte manages your project configuration through Git repositories.","title":"Creating Your First Taubyte Project"},{"content":"Building your own cloud infrastructure might sound daunting, but with Taubyte\u0026rsquo;s SporeDrive SDK, deploying a fully functional cloud to your servers takes just minutes. In this guide, we\u0026rsquo;ll walk through deploying a Taubyte cloud using infrastructure-as-code principles.\nPrerequisites Before we begin, you\u0026rsquo;ll need:\nInfrastructure: One or more servers (bare metal or VMs) running Linux with SSH access Domain: A fully qualified domain name with advanced DNS management capabilities SSH Access: SSH key access to your servers For this guide, we\u0026rsquo;ll use two servers and the domain k8s.cyou as an example.\nGetting Started with SporeDrive SporeDrive is available as an NPM package, as well as Go and Python packages. For this demonstration, we\u0026rsquo;ll use the NPM package. Start by cloning the boilerplate repository:\ngit clone https://github.com/taubyte/spore-drive-boilerplate cd spore-drive-boilerplate npm install The repository contains everything you need to get started, with SporeDrive listed as a dependency in package.json. The displace script in package.json is responsible for starting the deploy process to your hosts.\nConfiguration Environment Setup Copy the example environment file and configure it for your infrastructure:\ncp .env.example .env Now let\u0026rsquo;s go through each section of the .env file:\nServer Configuration\nThe first section handles SSH access to your servers. The SSH_KEY variable points to the PEM file that contains your server\u0026rsquo;s private SSH key. You\u0026rsquo;ll need to create this file in the root folder and add your private key, then save and exit.\nSSH_KEY=ssh-key.pem The SERVERS_CSV_PATH points to the hosts CSV file that should contain your infrastructure information. We\u0026rsquo;ll create this file next.\nSERVERS_CSV_PATH=hosts.csv The SSH_USER is the username to connect to your servers. This may differ depending on your server configuration (common values are ubuntu, root, or admin).\nSSH_USER=ssh-user Domain Configuration\nNext, we configure the domains. The ROOT_DOMAIN is your main domain that will be used for the Taubyte cloud infrastructure.\nROOT_DOMAIN=k8s.cyou The GENERATED_DOMAIN is used for development and testing purposes. This subdomain will be used for generated resources.\nGENERATED_DOMAIN=g.k8s.cyou DNS Configuration (Optional)\nThe last section is optional. You can add your domain provider\u0026rsquo;s information (in this case, Namecheap) to automatically configure DNS records, or you can set up the DNS manually.\nNAMECHEAP_API_KEY= NAMECHEAP_IP= NAMECHEAP_USERNAME= If you don\u0026rsquo;t provide DNS API information, the deployment will skip the DNS configuration step and you\u0026rsquo;ll need to configure the records manually.\nHosts Configuration After creating your .env file and SSH key, create a hosts.csv file in the root directory listing your servers. The CSV should contain the hostname and public IP of each host you are using:\nhostname,public_ip node1.k8s.cyou,203.0.113.1 node2.k8s.cyou,203.0.113.2 Understanding the Code The main deployment logic lives in src/index.ts. The source folder also contains helper files:\ncsv.ts: A helper for extracting hosts from the CSV file we created earlier. It gets the hostname and public IP of each host and returns them as records. namecheap.ts: The Namecheap DNS API client that allows for different operations on the API like setting and deleting DNS records. Let\u0026rsquo;s examine what happens when you run the deploy script:\n1. SDK Connection and Configuration Creation It all starts with the SDK connecting to the SporeDrive background service using RPC when we run our NPM displace script. At the top, we have all our imports including our specific SDK ones like the Config and Drive objects:\nimport { Config, CourseConfig, Drive, TauLatest, TauPath, Course, } from \u0026#34;@taubyte/spore-drive\u0026#34;; import fs from \u0026#34;fs\u0026#34;; import dotenv from \u0026#34;dotenv\u0026#34;; // Load .env file at the start dotenv.config(); import { getServersFromCSV } from \u0026#34;./csv\u0026#34;; import NamecheapDnsClient from \u0026#34;./namecheap\u0026#34;; It all starts with the SDK connecting to the SporeDrive background service using RPC when we run our NPM displace script:\nThe background service uses the Config object imported to create and initialize an empty config instance. This config instance can be in memory by default or written to disk at will:\nconst configPath = `${__dirname}/../config`; // Ensure config directory exists if (!existsSync(configPath)) { mkdirSync(configPath, { recursive: true }); } const config: Config = new Config(configPath); await config.init(); 2. Domain and Security Setup The createConfig function accepts the config instance and starts by setting the root and generated domains to the empty config using environment variables we set up earlier:\nexport const createConfig = async (config: Config) =\u0026gt; { await config .cloud.domain.root.set(process.env.ROOT_DOMAIN || \u0026#34;pom.ac\u0026#34;); await config .cloud.domain.generated.set(process.env.GENERATED_DOMAIN || \u0026#34;g.pom.ac\u0026#34;); It checks for domain validation and swarm keys and generates them if they don\u0026rsquo;t exist:\ntry { await config.cloud.domain.validation.keys.data.privateKey.get(); } catch { await config.cloud.domain.validation.generate(); } try { await config.cloud.p2p.swarm.key.data.get(); } catch { await config.cloud.p2p.swarm.generate(); } 3. SSH Authentication Setup Following that, it uses the SSH user environment variable and the private key file to establish an SSH connection to our hosts:\n// using SSH key for authentication const mainAuth = config.auth.signer[\u0026#34;main\u0026#34;]; await mainAuth.username.set(process.env.SSH_USER || \u0026#34;ssh-user\u0026#34;); const sshkey = await fs.promises.readFile(process.env.SSH_KEY || \u0026#34;ssh-key.pem\u0026#34;); await mainAuth.key.path.set(\u0026#34;keys/ssh-key.pem\u0026#34;); await mainAuth.key.data.set(sshkey); 4. Shape Definition It then creates a shape and calls it \u0026ldquo;all\u0026rdquo;. The shape is the number of services used in a single node. In this case, we are using all the available Taubyte cloud services in each node, and adding them to the shape, hence the name \u0026ldquo;all\u0026rdquo;. It continues with setting up the main and lite ports for the services and attaching them to the shape:\nconst all = config.shapes.get(\u0026#34;all\u0026#34;); await all .services .set([\u0026#34;auth\u0026#34;, \u0026#34;tns\u0026#34;, \u0026#34;hoarder\u0026#34;, \u0026#34;seer\u0026#34;, \u0026#34;substrate\u0026#34;, \u0026#34;patrick\u0026#34;, \u0026#34;monkey\u0026#34;]); await all.ports.port[\u0026#34;main\u0026#34;].set(4242); await all.ports.port[\u0026#34;lite\u0026#34;].set(4262); 5. Host Configuration It then lists the hosts from the config we passed to the hosts variable, and since the config is new, the hosts are empty. Then it creates a bootstrappers empty array:\nconst hosts = await config.hosts.list(); const bootstrapers = []; After that, it gets the servers using the getServersFromCSV function from the csv.ts helper file. It iterates through them and extracts the hostname and public IP of each:\nfor (const server of getServersFromCSV()) { const { hostname, publicIp } = server; If the current host is not included in the hosts list, it adds it to the hosts and the bootstrappers array. It sets addresses and locations from the current loop iteration server to the added host, checks if the added host includes the \u0026ldquo;all\u0026rdquo; shape, and if not, it generates it:\nif (!hosts.includes(hostname)) { const host = config.hosts.get(hostname); bootstrapers.push(hostname); await host.addresses.add([`${publicIp}/32`]); await host.ssh.address.set(`${publicIp}:22`); await host.ssh.auth.add([\u0026#34;main\u0026#34;]); await host.location.set(\u0026#34;40.730610, -73.935242\u0026#34;); if (!(await host.shapes.list()).includes(\u0026#34;all\u0026#34;)) await host.shapes.get(\u0026#34;all\u0026#34;).generate(); } } All that is left after the loop goes through all the servers is to add the bootstrapper array as nodes for node discovery, and it commits the changes to the config:\nawait config.cloud.p2p.bootstrap.shape[\u0026#34;all\u0026#34;].nodes.add(bootstrapers); await config.commit(); }; 6. Drive Creation and Deployment After creating the config, the background service creates a drive using the config and the build of Tau. By default, it uses the latest build, but you can change it to your specific one by providing a path using TauPath:\n// Use TauPath(\u0026#34;path/to/tau\u0026#34;) if you\u0026#39;d like to deploy your own build of tau const drive: Drive = new Drive(config, TauLatest); await drive.init(); It initializes the drive and plots a new course using the shape:\nconst course = await drive.plot(new CourseConfig([\u0026#34;all\u0026#34;])); Finally, it uses the keys and the displace script to deploy the Taubyte cloud to your nodes. Whilst doing that, it uses the displayProgress function, which creates a progress bar for each host to visualize the operation progress (optional and not mandatory):\nconsole.log(\u0026#34;Displacement...\u0026#34;); try { await course.displace(); await displayProgress(course); console.log(\u0026#34;[Done] Displacement\u0026#34;); } catch (e) { console.log(\u0026#34;Error displacing course:\u0026#34;, e); process.exit(1); } 7. DNS Configuration After the displacement, if you provided the DNS API information in the environment variables, it sets up the DNS with an A record for seer hosts that point to all the IP addresses of your nodes separately, an NS record for tau host that points to seer.your-root-domain, and finally, a wildcard CNAME record followed by your generated domain that points to substrate.tau.your-root-domain:\nconsole.log(\u0026#34;Update DNS Records...\u0026#34;); try { if (await fixDNS(config)) console.log(\u0026#34;[Done] DNS Records\u0026#34;); else console.log(\u0026#34;[Skip] DNS Records\u0026#34;); } catch (e) { console.log(\u0026#34;Error updating DNS records:\u0026#34;, e); process.exit(2); } If you don\u0026rsquo;t provide any DNS API information, it skips the operation.\nRunning the Deployment Execute the deploy script:\nnpm run displace SporeDrive will display progress bars for each host as it configures and deploys the Taubyte services.\nDNS Configuration After deployment, SporeDrive can automatically configure your DNS (if you provided API credentials). It creates:\nType Host Value A seer 203.0.113.1 A seer 203.0.113.2 NS tau seer CNAME *.g.k8s.cyou substrate.tau.k8s.cyou If you don\u0026rsquo;t provide DNS API credentials, you\u0026rsquo;ll need to configure these records manually with your DNS provider.\nVerifying Your Cloud Console Access Navigate to console.taubyte.com and:\nEnter your email Input your root domain (e.g., k8s.cyou) If the domain is accepted, your DNS is configured correctly Create Your First Project Once logged in, you\u0026rsquo;ll see the project management interface:\nClick Create Project Enter a project name Set visibility (public/private) Click Create This creates two GitHub repositories: one for configuration (YAML files) and one for your code.\nDeploy a Test Function Let\u0026rsquo;s verify everything works by deploying a simple function:\nNavigate to Functions in the sidebar Click the + button Select a template (e.g., Go ping/pong) Configure the domain and save Push your changes to GitHub The build will trigger automatically. Once complete, click the lightning icon next to your function to test it.\n# You should see: PONG Architecture Overview Here\u0026rsquo;s what you\u0026rsquo;ve just deployed:\n┌─────────────────────────────────────────────────────────────┐ │ Your Taubyte Cloud │ ├─────────────────────────────────────────────────────────────┤ │ Node 1 (203.0.113.1) │ Node 2 (203.0.113.2) │ │ ├── auth │ ├── auth │ │ ├── tns │ ├── tns │ │ ├── seer (DNS) │ ├── seer (DNS) │ │ ├── patrick (CI/CD) │ ├── patrick (CI/CD) │ │ ├── monkey (Build) │ ├── monkey (Build) │ │ ├── hoarder (Replication) │ ├── hoarder (Replication) │ │ └── substrate (Runtime) │ └── substrate (Runtime) │ ├─────────────────────────────────────────────────────────────┤ │ Peer-to-Peer Network │ │ (Secure, encrypted communication) │ └─────────────────────────────────────────────────────────────┘ What\u0026rsquo;s Next? With your Taubyte cloud deployed, you can:\nDeploy serverless functions in Go, Rust, or AssemblyScript Host static websites with automatic SSL certificates Create databases with automatic replication Set up storage buckets for object storage Implement pub/sub messaging for real-time applications Troubleshooting DNS not resolving?\nDNS propagation can take up to 48 hours Use dig or slimdig.com to verify records SSH connection failing?\nVerify your SSH key permissions: chmod 600 ssh-key.pem Confirm the SSH username matches your server configuration Console not accepting domain?\nEnsure the seer.tau.k8s.cyou NS record is properly configured Wait for DNS propagation and try again Conclusion You\u0026rsquo;ve just deployed your own cloud infrastructure capable of competing with major cloud providers. With SporeDrive, the entire process is codified, reproducible, and takes just minutes instead of months of engineering effort.\nThe infrastructure you\u0026rsquo;ve created supports serverless functions, static websites, databases, storage, and real-time messaging—all running on your own hardware with complete control over your data.\nFor more advanced configurations and detailed documentation, visit tau.how. Join our Discord community if you have questions or want to share what you\u0026rsquo;re building.\nNext: Run a cloud locally with Dream to start developing, or create your first project to begin building.\n","permalink":"/blog/posts/deploying-taubyte-cloud-with-sporedrive/","summary":"Learn how to deploy a complete Taubyte cloud infrastructure to your own servers using SporeDrive, our SDK for infrastructure-as-code deployments. This guide walks you through the entire process from configuration to running your first serverless function.","title":"Deploying Your Own Taubyte Cloud with SporeDrive"},{"content":"Testing modern cloud applications locally is a common challenge. Emulators and mocked environments often fail to replicate the true behavior of a distributed production cloud, leading to bugs that only appear after deployment.\nWhat if you could run a real cloud on your own machine?\nIntroducing Taubyte Dream Taubyte Dream lets you spin up a universe—a complete, self-contained Taubyte cloud running entirely on your local machine. This universe is an isolated peer-to-peer network of nodes, each running actual Taubyte services like gateway, substrate, and auth.\nThis design provides a development environment that closely mirrors working with a live remote cloud infrastructure.\nSimulation vs. Emulation: Why It Matters It\u0026rsquo;s crucial to understand that Dream provides a simulation, not an emulation.\nAspect Emulation Dream Simulation Behavior Approximates production Identical to production Code Different codebase Same software components Protocols Simplified versions Same protocols Testing confidence Medium High An emulation merely approximates behavior, which can lead to inconsistencies. In contrast, Dream\u0026rsquo;s simulation runs the exact same software components that exist in a live deployment. The services communicate using the same protocols and follow the same logic.\nThe only difference is the scale, not the substance.\nWhat you build and test in Dream will behave exactly as it would in a full-scale cloud.\nTrue Dev/Prod Parity The primary benefit of this approach is achieving true dev/prod parity. With Dream:\nCode and configuration tested locally can be deployed to production with zero changes No translation layers or environment-specific surprises Catch issues early in the development cycle Getting Started Installation First, ensure you have Node.js installed on your machine. Then install Dream globally:\nnpm install -g @taubyte/dream This makes the dream command available globally.\nCreating Your Cloud Initialize your local cloud with a single command:\ndream new multiverse You\u0026rsquo;ll see output confirming your cloud is running:\n[INFO] Dreamland ready [SUCCESS] Universe blackhole started! That\u0026rsquo;s it. You\u0026rsquo;ve just initialized a personal cloud on your machine.\nViewing Your Cloud To see all the running components of your universe:\ndream status universe This displays every service that makes up your cloud:\n┌───────┬─────────────────────┬────────┬───────┐ │ Nodes │ elder@blackhole │ p2p │ 14051 │ │ ├─────────────────────┼────────┼───────┤ │ │ tns@blackhole │ http │ 14466 │ │ ├─────────────────────┼────────┼───────┤ │ │ substrate@blackhole │ http │ 14529 │ │ ├─────────────────────┼────────┼───────┤ │ │ auth@blackhole │ p2p │ 14123 │ │ ... └───────┴─────────────────────┴────────┴───────┘ Each service functions just as it would in production.\nVisual Inspection with the Web Console You can also inspect your local cloud visually:\nOpen console.taubyte.com Click the Dreamland button (only visible when Dream is running) Navigate to Sidebar → Network → blackhole You\u0026rsquo;ll see a visual network graph showing all your running nodes and their connections.\nWorking with Your Local Cloud Connecting to the Console To add real code and test Taubyte functionalities:\nGo to console.taubyte.com Enter your email Select the network as blackhole Click Login with GitHub From here you can:\nCreate projects Define functions Manage applications Test databases and storage All while interacting with the cloud running on your machine.\nTesting a Function If you have a project imported or created:\nNavigate to Functions in the sidebar Find your function in the list Click the lightning icon to run it The function executes on your local cloud exactly as it would in production.\nExample: Running a Ping Function # First, find your substrate HTTP port dream status substrate # Then test your function curl -H \u0026#34;Host: your-domain.blackhole.localtau\u0026#34; http://127.0.0.1:14529/ping Response:\nPONG Key Dream Commands Command Description dream new multiverse Start a new local cloud dream status universe Show all running nodes dream status substrate Get substrate node details (for HTTP port) dream inject push-all Trigger builds for all repositories dream inject push-specific \u0026lt;id\u0026gt; Trigger build for specific repository The Architecture When you run Dream, it starts a complete peer-to-peer network locally:\n┌────────────────────────────────────────────┐ │ Local Dream Universe │ │ (blackhole) │ ├────────────────────────────────────────────┤ │ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ │ │ auth │ │ tns │ │ seer │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ └─────────────┼─────────────┘ │ │ │ │ │ ┌──────────┐ ┌────┴─────┐ ┌──────────┐ │ │ │ patrick │ │ substrate│ │ hoarder │ │ │ └────┬─────┘ └────┬─────┘ └────┬─────┘ │ │ │ │ │ │ │ └─────────────┴─────────────┘ │ │ P2P Network │ └────────────────────────────────────────────┘ Each node runs the same code as production, just scaled down to your local machine.\nWhy Dream Changes Everything Before Dream, local development for distributed cloud applications meant:\nSetting up mock services that behave differently than production Discovering bugs only after deployment Complex local environment configurations Environment-specific conditionals in code With Dream:\nTest production behavior locally before deploying No environment-specific code needed Faster development cycles with immediate feedback Confidence in deployments because local = production Conclusion Taubyte Dream eliminates the gap between development and production environments. By running an actual simulation of a Taubyte cloud on your local machine, you can develop, test, and debug with complete confidence that your code will behave identically in production.\nNo more \u0026ldquo;works on my machine\u0026rdquo; scenarios. No more deployment surprises. Just pure dev/prod parity.\nFor more details on Dream and all its capabilities, visit the documentation at tau.how. Join our Discord community if you have questions or want to connect with other developers.\nNext: Create your first project to start building on your local cloud.\n","permalink":"/blog/posts/run-real-cloud-locally-with-dream/","summary":"Testing cloud applications locally often means dealing with incomplete emulators that don\u0026rsquo;t match production behavior. Taubyte Dream changes this by running a complete, real cloud on your local machine—not an emulation, but an actual simulation of production infrastructure.","title":"Run a Real Cloud Locally with Taubyte Dream"},{"content":"When people first discover Taubyte, they usually ask one question:\n\u0026ldquo;Is this another cloud platform, or something fundamentally different?\u0026rdquo;\nThe short answer is: Taubyte is a different operating model.\nIt treats cloud development as code-first, Git-native, and ownership-driven. Instead of wiring products together through dashboards and one-off setup, you define behavior in versioned workflows and run them on infrastructure you control.\nThe philosophy in one sentence Taubyte helps teams build and ship faster without giving up control of where and how their cloud runs.\nThat philosophy is grounded in a few practical ideas.\n1) Own your cloud A lot of platforms optimize for convenience first and ownership second.\nTaubyte flips that priority:\nyou can deploy on infrastructure you control your architecture is not locked behind one vendor\u0026rsquo;s constraints your team can keep its operational model consistent across environments For engineering teams, this is less about ideology and more about risk management and long-term flexibility.\n2) Git is the API In Taubyte, Git is not just source control for app code. It is the operating interface for cloud changes.\nThat means the same mechanics your team already trusts apply to platform operations:\ncommits as atomic change units branches for isolated work pull requests for review and collaboration history for audit and rollback confidence When infrastructure and app behavior both follow Git workflows, teams spend less time reconciling \u0026ldquo;dashboard state\u0026rdquo; with \u0026ldquo;repo state.\u0026rdquo;\n3) Build local, run global Local development often breaks down in distributed systems because test environments are simplified too much.\nTaubyte addresses this with dream, a local cloud simulation approach that mirrors production behavior closely enough to catch real issues earlier.\nThe practical win is straightforward:\ntest workflows locally with meaningful confidence reduce environment-specific surprises promote changes with fewer translation steps 4) Automate operations, not just code Taubyte emphasizes autopilot-style workflows across build, test, and deployment paths.\nThis reduces operational drag for product teams and makes delivery pipelines more repeatable.\nThe goal is not to remove operators from the loop. It is to remove avoidable manual work from critical paths.\n5) Treat platform capabilities as built-in In many stacks, teams assemble core platform pieces manually and then maintain the glue forever.\nTaubyte\u0026rsquo;s model treats core capabilities as first-class concerns:\nservice discovery and routing certificate and trust workflows CI/CD event flow distributed communication patterns For builders, this means less time on platform plumbing and more time shipping product behavior.\nWhy this matters for teams Taubyte\u0026rsquo;s philosophy is useful because it connects three goals that are usually in tension:\nmove quickly keep systems understandable maintain infrastructure control When those three align, teams can scale development without increasing operational chaos at the same rate.\nFinal takeaway If you describe Taubyte as \u0026ldquo;cloud infra in a Git workflow,\u0026rdquo; you are close to the essence.\nIf you describe it as \u0026ldquo;local-first validation plus ownership-first deployment,\u0026rdquo; you are even closer.\nThat is the core model: build with speed, ship with confidence, and stay in control of your cloud.\nSources Taubyte Tau documentation Local cloud workflow ","permalink":"/blog/posts/taubyte-explained-own-your-cloud-with-git-native-workflows/","summary":"A plain-English explanation of Taubyte\u0026rsquo;s core philosophy: infrastructure ownership, Git-native operations, local-first validation, and automated workflows.","title":"Taubyte Explained: Own Your Cloud with Git-Native Workflows"},{"content":"In many platforms, GitHub integration means \u0026ldquo;connect your repo and hope the webhook setup is correct.\u0026rdquo;\nTau aims for something cleaner: Git workflows become the control plane for deployment behavior.\nThis post explains that model in plain language.\nThe core idea In Tau, repositories are not just storage for source code.\nThey are workflow triggers, collaboration boundaries, and change history for both application logic and platform behavior.\nThat means GitHub integration is not an add-on. It is part of the operating model.\nWhat the GitHub client layer does From the repository structure, the GitHub integration layer focuses on practical repository operations such as:\ncreating repositories listing and discovering repositories retrieving repository identity and metadata handling authenticated requests to GitHub APIs In other words, it gives Tau workflows a consistent way to interact with GitHub as a system dependency.\nWhy this is useful for teams When repository operations are formalized in the platform model:\nonboarding gets easier because workflows are predictable automation can rely on stable repo metadata and IDs operational actions are easier to audit through Git history teams spend less time fixing one-off integration scripts This is where Git-native infrastructure starts to feel practical in day-to-day work.\nA simple workflow mental model Think in this sequence:\nrepositories are created or connected changes are authored through normal Git collaboration platform workflows react to repository events build/deploy operations follow repeatable rules teams inspect outcomes and iterate through new commits The value is not the individual step. It is the consistency of the entire loop.\nLocal-first + GitHub integration Tau\u0026rsquo;s local cloud workflows and GitHub integration complement each other:\nlocal environments help you validate changes early GitHub-backed flows preserve review and history production promotion keeps the same mental model as local iteration This helps reduce the classic \u0026ldquo;worked locally, broke in CI\u0026rdquo; gap.\nCommon anti-patterns treating GitHub integration as a one-time setup task mixing manual dashboard operations with untracked repo changes relying on implicit branch behavior without clear team conventions coupling deployment logic to personal scripts instead of shared workflows A Git-native model works best when team conventions are explicit and repeatable.\nFinal takeaway Tau\u0026rsquo;s GitHub integration is about turning repositories into reliable workflow units, not just connecting an external provider.\nWhen teams use Git as the source of truth for both code and platform behavior, delivery becomes easier to reason about, easier to audit, and easier to scale.\n","permalink":"/blog/posts/github-integration-in-tau-how-repositories-become-deployable-workflows/","summary":"A plain-English walkthrough of Tau\u0026rsquo;s GitHub integration model, from repository management to repeatable deployment workflows.","title":"GitHub Integration in Tau: How Repositories Become Deployable Workflows"},{"content":"In this article, I\u0026rsquo;ll go over how to use the LLM (or GPT) capabilities of taubyte-llama-satellite. I\u0026rsquo;m assuming that you already know how to create a project and a function on a Taubyte-based Cloud Computing Network. If not, please refer to Taubyte\u0026rsquo;s Documentation.\nLLAMA Satellite A Taubyte Cloud can provide LLM capabilities through what we call a Satellite. In this case it\u0026rsquo;s taubyte-llama-satellite which exports llama.cpp capabilities to the Taubyte Virtual Machine, thus giving Serverless Functions (or DFunctions, as per Taubyte\u0026rsquo;s terminology) LLM features.\nLLAMA SDK Satellites export low-level functions that aren\u0026rsquo;t very intuitive to use directly. Fortunately, it\u0026rsquo;s possible to address that with a user-friendly SDK. The Go SDK for taubyte-llama-satellite can be found here.\nGet Ready Before proceeding, let\u0026rsquo;s ensure you have a project and a DFunction ready to go. If not, please refer to \u0026ldquo;Create a Function\u0026rdquo;.\nLet\u0026rsquo;s Code! A good practice is to clone your code locally using git or the tau command-line. Make sure you have Go installed, then run:\ngo get github.com/samyfodil/taubyte-llama-satellite Our Basic Function If you followed the steps from Taubyte\u0026rsquo;s Documentation, your basic function should look something like this:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; ) //export ping func ping(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } h.Write([]byte(\u0026#34;PONG\u0026#34;)) return 0 } Let\u0026rsquo;s modify it so it uses the POST body as the prompt. Note: I\u0026rsquo;ve changed the function\u0026rsquo;s name to predict. Ensure this change is reflected in your configuration by setting the entry point to predict and modifying the method from GET to POST.\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } return 0 } Predict The LLAMA SDK exports two main methods, Predict and Next. Let\u0026rsquo;s start by creating a prediction:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;github.com/samyfodil/taubyte-llama-satellite/sdk\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } p, err := sdk.Predict( string(prompt), ) if err != nil { panic(err) } return 0 } This code will submit a request for a prediction to the satellite, which will put it in a queue because predictions are resource-intensive (especially on the GPU), and return a prediction.\nJust like when interacting with any LLM, you can customize the request like so:\np, err := sdk.Predict( string(prompt), sdk.WithTopK(90), sdk.WithTopP(0.86), sdk.WithBatch(512), ) You can find all possible options here.\nGet Tokens After submitting a prediction to the satellite, you need to collect tokens. You can do so by calling p.Next(), which will block until a new token is available or the prediction is completed or canceled. Note that you can use NextWithTimeout if you\u0026rsquo;d like to set a deadline.\nNow, let\u0026rsquo;s wrap up our function:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;github.com/samyfodil/taubyte-llama-satellite/sdk\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } p, err := sdk.Predict( string(prompt), sdk.WithTopK(90), sdk.WithTopP(0.86), sdk.WithBatch(512), ) if err != nil { panic(err) } for { token, err := p.Next() if err == io.EOF { break } else if err != nil { panic(err) } h.Write([]byte(token)) h.Flush() //flush } return 0 } The call to h.Flush() will send the token to the client (browser) immediately. If you\u0026rsquo;d like to recreate the AI typing experience provided by ChatGPT, you can use something like:\nawait axios({ method: \u0026#34;post\u0026#34;, data: prompt, url: \u0026#34;\u0026lt;URL\u0026gt;\u0026#34;, onDownloadProgress: (progressEvent) =\u0026gt; { const chunk = progressEvent.currentTarget.responseText; gotToken(chunk); }, }) Conclusion In this guide, we\u0026rsquo;ve walked through how to leverage the LLM (or GPT) capabilities provided by 8ws on a Taubyte-based Cloud Computing Network. We\u0026rsquo;ve explored the concept of a LLAMA Satellite and its role in exporting LLM capabilities to the Taubyte Virtual Machine. Furthermore, we\u0026rsquo;ve discussed the importance and functionality of the LLAMA SDK, which makes interacting with the Satellite\u0026rsquo;s low-level functions more intuitive.\nWe\u0026rsquo;ve gone through a practical example of how to use these tools in a Taubyte project, specifically demonstrating how to fetch tokens and use the Predict method. We\u0026rsquo;ve also shown how you can fine-tune your requests to the SDK and manage the tokens returned by the Satellite. By the end of the guide, you should be equipped to create a serverless function on Taubyte that can generate predictions from user-provided prompts, similar to how AI like ChatGPT works.\nHarnessing the power of Taubyte and the LLAMA Satellite, you\u0026rsquo;re now ready to incorporate large language model capabilities into your projects, bringing a new level of interactivity and AI-driven responses to your applications.\n","permalink":"/blog/posts/build-your-cloud/","summary":"Add LLAMA Capability to Your Cloud","title":"Add LLAMA Capability to Your Cloud"},{"content":"In modern e-commerce, latency is a revenue killer. When a user clicks \u0026ldquo;Buy,\u0026rdquo; they expect instant feedback. From a systems perspective, the goal is to keep the hot path (customer interaction) short, predictable, and failure-tolerant, without compromising inventory correctness or auditability.\nInspired by the article Serverless Order Management using AWS Step Functions and DynamoDB, we’ll take a sovereignty- and security-first approach to build a high-speed, resilient order workflow using Taubyte, optimized for the moment that matters: when a customer presses “Buy.”\nInstead of coupling checkout to a centralized database write (or a long orchestration chain), we separate concerns:\nHot path: accept the order, take payment, reserve stock (fast, close to users) Cold path: reconcile final state into the system of record, with retries and observability The Challenge: Speed vs. Consistency Traditional order processing systems face a fundamental trade-off:\nFast systems can become risky (overselling, partial failures, messy recovery) Strongly consistent systems often feel slow because every step synchronizes on a central system of record Orchestrated workflows add hop count, state management overhead, and complicated failure handling Our Taubyte-based architecture solves all three problems simultaneously.\nThe Architecture Overview We remove the “central database bottleneck” from the customer checkout experience by using a familiar distributed-systems pattern:\nWrite-ahead state in a fast distributed store (orders, payment status, reservation state) Background convergence to the system of record (ERP/OMS/warehouse DB) with retries The Taubyte building blocks (architect view):\nFunctions: stateless request handlers and workflow steps (hot path + background steps) Distributed caches: low-latency, globally available key-value stores for orders and stock state Scheduled jobs: periodic reconciliation tasks (inbound inventory refresh, outbound order finalization) Below is the complete workflow we will be implementing.\n(Caption: The complete asynchronous order processing and synchronization workflow.)\nThe Workflow: The \u0026ldquo;Hot Path\u0026rdquo; The initial steps must be fast because they are directly tied to conversion rate. The key design decision: avoid blocking the checkout flow on synchronous writes to the system of record.\n1. Order Registration \u0026amp; Caching The process begins when a user submits an order. A Taubyte function handles the request and responds quickly. (Under the hood, Taubyte uses WebAssembly for fast startup, reducing cold-start impact.)\nInstead of going straight to a heavyweight database, the function immediately writes the order to the Order Cache. Think of this as the workflow’s durable “working set” during checkout: the order state machine lives here until it is finalized.\n2. Payment Processing Next comes payment. A function calls your Payment Provider (e.g., Stripe). The result (success/failure) is written back into the Order Cache immediately, keeping the workflow state centralized without involving the system of record in the hot path.\n(Caption: The high-speed intake. User requests are immediately accepted and stored in a fast distributed cache, decoupling the user from backend complexity.)\nThe Inventory Decision Engine (Preventing Oversell) The most critical risk here is overselling. We prevent it without slowing down checkout by using a fast inventory working set and reservation semantics in the hot path, then reconciling with the back-office system afterward.\n3. The Inventory Check When it’s time to confirm availability, we don’t call a distant back-office inventory system in the middle of the checkout. We query the Stock Cache instead, a fast working set that holds the latest available counts per item.\nThe logic is simple:\nFetch: Get current item count from the Stock Cache. Decision: If inventory is available (at least one unit): Proceed to fulfillment. If inventory is not available (zero units), or payment failed: Proceed to refund. Branch A: Fulfillment (The Happy Path) If stock is available, we proceed to fulfillment. At this moment, we reserve the inventory immediately in the Stock Cache so two customers can’t buy the last unit at the same time. In practice, this implies a safe “reserve” operation and a clear policy for releasing reservations on failure or timeout.\nBranch B: Refund (The Failure Path) If the cache indicates out-of-stock (or payment failed), we trigger a refund and notify the customer. The key is that failure handling is part of the workflow, not an afterthought.\n(Caption: The decision engine. The system uses a fast cache lookup to determine available stock, splitting the workflow into fulfillment or refund paths.)\nThe Secret Sauce: Asynchronous Synchronization You might be asking: “If we’re using a distributed working set to go fast, how do we guarantee correctness and auditability?”\nThe answer is background reconciliation: accept and process orders quickly, then converge final state into the system of record with retryable, observable workers.\nThe Inbound Sync (Keeping Stock Accurate) We cannot rely solely on the cache forever, as inventory might change due to external factors (e.g., warehouse restocks).\nWe define a Taubyte scheduled job that runs periodically (e.g., every 5 minutes).\nTask: Pull the latest inventory from your system of record (ERP/warehouse DB/API) and refresh the Stock Cache. This bounds drift and makes cache-based decisions reliable. The Outbound Sync (Finalizing Orders) Once an order reaches the \u0026ldquo;Fulfill\u0026rdquo; or \u0026ldquo;Refund\u0026rdquo; state in the hot path, it needs to be permanently recorded.\nA background sync process reads final order state from the Order Cache and writes it to your system of record. This is where you enforce durable invariants: exactly-once accounting, idempotent updates, and audit trails.\n(Caption: The synchronization layer. Background scheduled (timer) functions ensure the fast caches are eventually consistent with the persistent Source of Truth database.)\nWhy This Architecture Wins By adopting this Taubyte-based architecture, we gain significant advantages over traditional serverless approaches:\nUnmatched Speed: Using lightweight functions and distributed caches means the user experience is incredibly snappy, with minimal startup overhead. Resilience: If the main \u0026ldquo;Source of Truth\u0026rdquo; database goes offline for maintenance, the system can still accept and process orders using the cached data. Operational Simplicity: There is no complex console to manage infrastructure. The entire workflow (functions, databases, and timers) is defined in code, making deployments deterministic and instant. AWS vs Taubyte: Data Sovereignty and Control For systems architects, sovereignty questions translate into concrete constraints: where workloads run, who operates the control plane, where data is stored/processed, and how hard boundaries are enforced.\nBoth AWS and Taubyte can support high-scale systems, but they differ significantly in sovereignty posture.\nTopic AWS (typical managed approach) Taubyte (self-host or your chosen infrastructure) Control plane ownership Provider-operated control plane for managed services Autopilot-operated platform under your governance: you control where it runs and the policies; Autopilot handles day‑2 operations on your infrastructure (or a trusted operator’s) Residency boundaries Region selection + service constraints; still provider infrastructure Hard boundaries: choose country/region/operator/on‑prem and keep execution/data within that footprint Compliance posture Shared responsibility model; compliance depends on service selection and configuration Compliance posture can be aligned to internal controls because execution plane and data plane are operator-controlled Portability / lock-in Higher when deeply coupled to managed orchestration/datastores Lower: same model can run across environments you control Failure domains Bounded by provider regions/services Architected around your chosen failure domains; can keep hot path operating despite system-of-record outages In short: AWS is great when “region choice” is enough. Taubyte is compelling when you need operational control and enforceable residency boundaries, for example, strict data residency, sector regulations, or sovereign deployments.\nArchitectural Considerations (What Architects Will Care About) State model: treat Order Cache as the workflow state machine (e.g., registered → paid → reserved → fulfilled/refunded → synced). Idempotency: every step (payment update, reservation, fulfillment, refund, sync) must be safe to retry. Delivery semantics: assume “at-least-once” execution for background jobs; design deduplication keys and idempotent writes. Reservation policy: define reservation TTLs, release rules, and reconciliation behavior when the system of record disagrees. Consistency guarantees: be explicit about where you require strong consistency (reservation) vs eventual convergence (sync to system of record). Back-pressure \u0026amp; throttling: protect payment provider and system-of-record APIs with rate limits and queues. Observability: trace an order end-to-end (correlation IDs), expose workflow metrics (conversion, refund rate, reservation contention), and alert on sync lag. Security boundaries: isolate secrets (payment keys), minimize PII in caches, and ensure encryption + access controls at rest and in transit. Conclusion Building a resilient, low-latency order processing system doesn\u0026rsquo;t require complex orchestration tools or sacrificing speed for consistency. With Taubyte, you can keep the customer path fast using lightweight functions and distributed caches, while keeping the system of record accurate through background reconciliation.\nThe architecture we\u0026rsquo;ve outlined (edge caching for speed, asynchronous synchronization for accuracy) represents a modern approach to e-commerce infrastructure that scales with your business while keeping operational complexity minimal.\nNext Steps Ready to build your own high-performance order processing system? Here\u0026rsquo;s how to get started:\nSet up Taubyte locally: Install Dream to create a local cloud environment for rapid development and testing Define your functions: Start with the order registration function using Taubyte\u0026rsquo;s HTTP functions Configure distributed caches: Set up your Order Cache and Stock Cache using Taubyte\u0026rsquo;s databases capabilities Implement sync workers: Create scheduled (timer) functions for bidirectional synchronization with your source of truth Test and deploy: Use Taubyte\u0026rsquo;s local development tools to test the complete workflow before deploying to production ","permalink":"/blog/posts/building-resilient-low-latency-order-processing-system-taubyte/","summary":"\u003cp\u003eIn modern e-commerce, \u003cstrong\u003elatency is a revenue killer\u003c/strong\u003e. When a user clicks \u0026ldquo;Buy,\u0026rdquo; they expect instant feedback. From a systems perspective, the goal is to keep the \u003cstrong\u003ehot path\u003c/strong\u003e (customer interaction) short, predictable, and failure-tolerant, without compromising inventory correctness or auditability.\u003c/p\u003e\n\u003cp\u003eInspired by the article \u003ca href=\"https://towardsaws.com/serverless-order-management-using-aws-step-functions-and-dynamodb-352d83fda8f7\"\u003eServerless Order Management using AWS Step Functions and DynamoDB\u003c/a\u003e, we’ll take a \u003cstrong\u003esovereignty- and security-first approach\u003c/strong\u003e to build a \u003cstrong\u003ehigh-speed, resilient order workflow\u003c/strong\u003e using \u003cstrong\u003eTaubyte\u003c/strong\u003e, optimized for the moment that matters: when a customer presses “Buy.”\u003c/p\u003e","title":"Building a Resilient, Low Latency Order Processing System with Taubyte"},{"content":"In the modern cloud era, businesses are embracing cloud services at an unprecedented rate. From AI-powered analytics to scalable storage, the cloud promises agility, speed, and cost efficiency. But along with these benefits comes a growing concern: security.\nCyberattacks are becoming more sophisticated, and high-profile breaches in public cloud environments have highlighted that storing sensitive data on someone else\u0026rsquo;s infrastructure carries inherent risks. Companies are increasingly asking themselves: Who really controls my data?\nThe Rise of Data Sovereignty Concerns Data sovereignty refers to the principle that data is subject to the laws and regulations of the country in which it is stored. For many organizations, particularly in finance, healthcare, and government sectors, compliance with local regulations is not optional—it\u0026rsquo;s mandatory.\nRelying on global cloud providers can introduce significant challenges:\nJurisdiction risks: Your data might reside in a country with conflicting privacy laws or regulations that don\u0026rsquo;t align with your business requirements. Regulatory compliance: Some industries require complete control over where data lives and who can access it, making third-party cloud storage a compliance risk. Transparency issues: Companies may struggle to verify how cloud providers manage, replicate, or secure their data across different regions and data centers. These concerns have made self-hosting an increasingly attractive alternative. By managing your own infrastructure, you retain full control, visibility, and compliance over your data while maintaining the flexibility to adapt to changing regulatory requirements.\nWhy Self-Hosting Makes Sense Self-hosting offers several compelling advantages for security-conscious organizations:\nEnhanced Security: You control access, monitoring, and encryption protocols. No third-party has implicit access to your sensitive data or infrastructure. Full Compliance: Data stays under your jurisdiction, simplifying adherence to local laws, industry regulations, and international data protection standards like GDPR. Customization: Tailor infrastructure to your specific security and performance needs without being constrained by a provider\u0026rsquo;s one-size-fits-all approach. Cost Optimization: Avoid hidden fees of public cloud while gaining predictable operational costs and better long-term budget planning. Resilience: Reduce dependency on external providers; maintain operations even if cloud platforms face outages or service disruptions. Taubyte: The Modern Approach to Self-Hosting Self-hosting doesn\u0026rsquo;t have to mean complex setups or heavy DevOps work. Modern platforms like Taubyte are designed to make self-hosting easier, scalable, and cloud-like in capabilities while maintaining complete data sovereignty.\nTaubyte allows companies to:\nDeploy functions, databases, and APIs on their own infrastructure with edge-native performance. Retain full control over data while enjoying the flexibility and speed of modern cloud architecture. Automate operations similar to cloud platforms without sacrificing sovereignty or security. Leverage edge computing capabilities to reduce latency and improve user experience. Scale seamlessly across distributed infrastructure while maintaining data locality and compliance. By combining the security and control of self-hosting with the flexibility and speed of modern cloud architecture, Taubyte offers a compelling solution for companies looking to regain control over their digital assets without compromising on performance or developer experience.\nGetting Started with Taubyte If you\u0026rsquo;re considering self-hosting as a strategic move for your organization, Taubyte provides comprehensive documentation and guides to help you get started. Whether you\u0026rsquo;re deploying serverless functions, managing databases, or building edge-native applications, Taubyte\u0026rsquo;s platform simplifies the complexity of self-hosted infrastructure while maintaining the agility your development teams need.\nLearn more about Taubyte\u0026rsquo;s self-hosting capabilities and discover how you can build a secure, compliant, and scalable infrastructure on your own terms.\nConclusion As security threats grow and regulations tighten, businesses are reassessing the traditional cloud model. Data sovereignty and control are no longer optional—they are essential. Self-hosting, especially with modern tools like Taubyte, empowers organizations to secure their data, ensure compliance, and maintain operational flexibility without sacrificing the benefits of cloud-native development.\nIn a world where data is gold, controlling your own infrastructure is no longer just an option—it\u0026rsquo;s a strategic advantage that can differentiate your business in an increasingly competitive and regulated landscape.\nReady to take control of your infrastructure? Explore Taubyte\u0026rsquo;s self-hosting solutions and discover how modern self-hosting can transform your approach to cloud computing while maintaining complete data sovereignty and security.\n","permalink":"/blog/posts/why-security-data-sovereignty-driving-companies-toward-self-hosting/","summary":"As cyberattacks become more sophisticated and data regulations tighten, companies are increasingly turning to self-hosting solutions. Discover why data sovereignty and security are driving businesses away from traditional cloud providers and how modern platforms like Taubyte are making self-hosting easier, scalable, and cloud-like in capabilities while maintaining full control over sensitive data.","title":"Why Security and Data Sovereignty Are Driving Companies Toward Self-Hosting"},{"content":"In this tutorial, we’ll go step by step through building a fully functional online marketplace using Taubyte. The focus is on a smooth “vibe coding” experience - local development first, then pushing to production.\nStep 1: Setting Up Locally and Creating a Universe We start by creating a local environment using the Dream Desktop program.\nOpen Dream Desktop and create a Universe. 2. Connect to it via the console at console.taubyte.com.\nChoose the universe, enter your email, and connect with GitHub. Create a project in the console. Step 2: Understanding Frontend and Backend Our marketplace has two main parts: frontend and backend.\nWe’ll start with the backend. The backend is made of multiple services, each responsible for a single function. Our first service is Auth Service.\nCreate an application for the Auth Service.\nStep 3: Pushing from Dream Desktop Once the application is ready:\nPush all changes from Dream Desktop. Normally, builds are triggered automatically via a webhook from GitHub. Locally, simulate this webhook with a push button on Dream Desktop. This creates a local test cloud instead of deploying to a production node. Step 4: Creating Serverless Functions We won’t use inline code for serverless functions - it’s messy to maintain. Instead:\nUse Taubyte libraries (distinct Git repos) as the code source. Each serverless function takes its code from the library. Steps:\nPush the config from the console. Push again from Dream Desktop. Clone the backend library from GitHub. Step 5: Auth Service API We’ll use agents.doc as documentation. Prompt your AI to generate code:\n\u0026#34;Create a fully functioning simple Auth CRUD API using JWT. Use different files for organization. Use only simple and necessary code. Use agents.doc as docs for Taubyte.\u0026#34; The AI generates:\nHandlers \u0026amp; exported logic → serverless functions. Serverless function endpoints:\nFunction Path login /api/auth/login register /api/auth/register updateUser /api/auth/updateuser deleteUser /api/auth/deleteuser getUser /api/auth/getuser Step 6: Push and Configure Serverless Functions Push to GitHub, then create serverless functions in the console:\nSet timeout and path. Pick the domain. Source code = backend library. Entry point = exported function from Go library. Push console config, then push build from Dream Desktop. Step 7: Database Setup Create a database from the console called data. Push again from the console after creation. Step 8: Testing Endpoints with Curl (Using JWT) Use the following curl commands to test your Auth Service:\nRegister User\ncurl -X POST \u0026lt;BASE_URL\u0026gt;/api/auth/register \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{\u0026#34;username\u0026#34;:\u0026#34;testuser\u0026#34;,\u0026#34;email\u0026#34;:\u0026#34;test@example.com\u0026#34;,\u0026#34;password\u0026#34;:\u0026#34;password\u0026#34;}\u0026#39; Login User (Get JWT Token)\ncurl -X POST \u0026lt;BASE_URL\u0026gt;/api/auth/login \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{\u0026#34;email\u0026#34;:\u0026#34;test@example.com\u0026#34;,\u0026#34;password\u0026#34;:\u0026#34;password\u0026#34;}\u0026#39; The response will return a JSON containing the token. Use this token for the next requests.\nGet User\ncurl -X GET \u0026lt;BASE_URL\u0026gt;/api/auth/getuser \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer \u0026lt;JWT_TOKEN\u0026gt;\u0026#34; \\ -d \u0026#39;{\u0026#34;id\u0026#34;:\u0026#34;\u0026lt;USER_ID\u0026gt;\u0026#34;}\u0026#39; Update User\ncurl -X PUT \u0026lt;BASE_URL\u0026gt;/api/auth/updateuser \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer \u0026lt;JWT_TOKEN\u0026gt;\u0026#34; \\ -d \u0026#39;{\u0026#34;id\u0026#34;:\u0026#34;\u0026lt;USER_ID\u0026gt;\u0026#34;, \u0026#34;username\u0026#34;:\u0026#34;updatedName\u0026#34;}\u0026#39; Delete User\ncurl -X DELETE \u0026lt;BASE_URL\u0026gt;/api/auth/deleteuser \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer \u0026lt;JWT_TOKEN\u0026gt;\u0026#34; \\ -d \u0026#39;{\u0026#34;id\u0026#34;:\u0026#34;\u0026lt;USER_ID\u0026gt;\u0026#34;}\u0026#39; Backend library example: tb_library_auth_service\nStep 9: Frontend Setup Create a global website empty repo. Push to GitHub, then open it in Dream Desktop.\nUse Vite + VueJS + Tailwind to create a frontend project.\nKeep the .taubyte folder created by Taubyte (essential for build). Prompt AI:\n\u0026#34;Use TailwindCSS to create a minimalist elegant Auth page. Use the .env file for the base URL. Use window.location.origin for API calls.\u0026#34; Include the curl commands above for reference. Test locally, make tweaks, then push to GitHub to trigger a build via Dream Desktop. Step 10: Final Config Tweaks Add build.sh and config.yaml in .taubyte folder for Vite projects. Update serverless function domains if needed. Push console config and trigger build. Visit your website via the lightning button in the console. Important: Ensure the library domain and website domain match. Otherwise, window.location.origin won’t work correctly.\nConclusion Following these steps, you now have a fully functioning online marketplace built on Taubyte, complete with backend services, JWT-secured serverless functions, a database, and a minimal VueJS + Tailwind frontend.\nThis approach keeps everything modular, maintainable, and ready for production while allowing you to vibe code locally.\n","permalink":"/blog/posts/create-an-online-marketplace-pt1/","summary":"Step-by-step tutorial on creating a full online marketplace using Taubyte. Covers setting up a local development environment with Dream Desktop, creating a universe, building modular backend services like Auth Service with serverless functions, configuring a database, setting up a minimal VueJS + Tailwind frontend, and deploying everything via Taubyte while maintaining a smooth local “vibe coding” workflow.","title":"Build with Taubyte: Online Marketplace Part 1"},{"content":"In the first article, we built the AuthService - the backbone of user authentication in our Taubyte-powered marketplace. Today, we move to the UserService, the part of the backend responsible for user profiles, settings, password changes, and preferences.\nJust like before, everything is created locally using Dream Desktop, then pushed and deployed through console.taubyte.com, following the same “local first → production later” workflow.\n1. Start Your Universe Before anything else, start the same universe we created in Part 1.\nOpen console.taubyte.com, select your universe, and enter the dashboard.\n2. Create the UserService Application Inside the Applications tab, create a new UserService library. This service will handle:\nFetching the user profile Updating profile details Changing password Updating language / notification / display preferences Just like AuthService, we don’t write inline code. We create a dedicated backend library.\n3. Create the Backend Library (Golang) Create a new Golang library named user-service.\nPush from Dream Desktop to generate the config + code build jobs.\nOnce both jobs succeed, open your editor (Cursor) and clone the repo:\ngit clone https://github.com/.../tb_library_user_service Rename the entry file, tidy dependencies:\ngo mod tidy Now the library is ready for code.\n4. Use AI to Generate the UserService Code Inside Cursor, clone the library repository then prompt the AI with the following:\nCreate a CRUD user service with these routes: - get user profile - update profile - change password - update preferences (language, notifications, display) Use this model: User { ID (same as Auth service) name email phone address preferences { language, notifications, display } role (buyer, seller, admin) } Use the planning method. AI generates the plan, then builds:\nmodel.go\njwt.go (token validation copied from AuthService)\ndatabase.go\nutils.go\nhandlers.go with 4 exported functions:\nGetUserProfile UpdateUserProfile ChangePassword UpdatePreferences You now have a complete backend.\nPush it:\ngit add . git commit -m \u0026#34;Initial user service\u0026#34; git push 5. Create Serverless Functions in the Console Go to Functions → Create Function and create four serverless functions, each using the user-service library as the source and the exported handler as the entry point.\n1. Get User Profile Method: GET Path: /api/users Entry point: GetUserProfile 2. Update User Profile Method: PUT Path: /api/users Entry point: UpdateUserProfile 3. Change Password Method: PUT Path: /api/users/password Entry point: ChangePassword 4. Update Preferences Method: PUT Path: /api/users/preferences Entry point: UpdatePreferences Push the config from the console, then push again from Dream Desktop to trigger builds.\n6. Test the Endpoints with Curl Remember: all UserService routes are protected. You must log in first → get a token → use it in Authorization header.\nLogin to get token (from Part 1) curl -X POST https://YOUR_DOMAIN/api/auth/login \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -d \u0026#39;{\u0026#34;email\u0026#34;:\u0026#34;test@test.com\u0026#34;,\u0026#34;password\u0026#34;:\u0026#34;123456\u0026#34;}\u0026#39; Response:\n{ \u0026#34;token\u0026#34;: \u0026#34;YOUR_JWT_TOKEN\u0026#34; } Use this token in all next requests:\n-H \u0026#34;Authorization: Bearer YOUR_JWT_TOKEN\u0026#34; 1. Get Profile curl -X GET https://YOUR_DOMAIN/api/users \\ -H \u0026#34;Authorization: Bearer YOUR_JWT_TOKEN\u0026#34; 2. Update Profile curl -X PUT https://YOUR_DOMAIN/api/users \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer YOUR_JWT_TOKEN\u0026#34; \\ -d \u0026#39;{ \u0026#34;id\u0026#34;:\u0026#34;user id\u0026#34;, \u0026#34;name\u0026#34;:\u0026#34;New Name\u0026#34;, \u0026#34;email\u0026#34;:\u0026#34;new@mail.com\u0026#34;, \u0026#34;phone\u0026#34;:\u0026#34;0555000000\u0026#34;, \u0026#34;address\u0026#34;:\u0026#34;New address\u0026#34; }\u0026#39; 3. Change Password curl -X PUT https://YOUR_DOMAIN/api/users/password \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer YOUR_JWT_TOKEN\u0026#34; \\ -d \u0026#39;{ \u0026#34;oldPassword\u0026#34;:\u0026#34;123456\u0026#34;, \u0026#34;newPassword\u0026#34;:\u0026#34;abcdef\u0026#34; }\u0026#39; 4. Update Preferences curl -X PUT https://YOUR_DOMAIN/api/users/preferences \\ -H \u0026#34;Content-Type: application/json\u0026#34; \\ -H \u0026#34;Authorization: Bearer YOUR_JWT_TOKEN\u0026#34; \\ -d \u0026#39;{ \u0026#34;language\u0026#34;:\u0026#34;en\u0026#34;, \u0026#34;notifications\u0026#34;:true, \u0026#34;display\u0026#34;:\u0026#34;dark\u0026#34; }\u0026#39; 7. Build the Frontend for UserService Now that the backend is ready, we extend the frontend (created in Part 1).\nOpen Cursor and prompt:\nContinue implementing the UserService frontend. Use the token from login and call all CRUD endpoints. Use environment variables for BASE_URL. Update dashboard UI. AI generates:\nAPI client functions UI logic Form components Error handling Push the frontend to github:\ngit add . git commit -m \u0026#34;UserService frontend\u0026#34; git push Trigger a build from Dream Desktop.\nIf the build fails, copy the error logs → paste into AI → fix → push again.\nOnce the job succeeds, visit your deployed website using the lightning button next to the website on the right.\n8. Full Frontend Flow Register Login Token stored Token used for all secure requests Profile loads correctly Updating profile works Changing password works Preferences update instantly Conclusion In Part 2, we created a complete UserService:\nBackend library AI-generated CRUD logic JWT-protected routes Serverless functions Curl-tested endpoints Frontend integration Your marketplace now has:\nAuthentication User profiles Preferences system ","permalink":"/blog/posts/create-an-online-marketplace-pt2/","summary":"Focuses on creating a User Service for managing user profiles and settings within the marketplace. Shows how to set up the service application in Taubyte, define API endpoints for CRUD operations on users, push changes via Dream Desktop, configure serverless functions, connect to the database, and test endpoints. Emphasizes modular design and using AI for generating boilerplate code while keeping local development first.","title":"Build with Taubyte: Online Marketplace Part 2"},{"content":"The cloud computing market is experiencing exponential growth, driven by technological advancements and the increasing demand for scalable and efficient IT solutions. The market size, valued at USD 546.1 billion in 2022, is projected to grow at a compound annual growth rate (CAGR) of 14.1% from 2023 to 2030. This robust growth trajectory is fueled by the widespread adoption of cloud services across various sectors, enhancing operational efficiency, flexibility, and cost-effectiveness.\nAI Integration in Cloud Computing Artificial intelligence (AI) is a significant catalyst in the evolution of cloud computing, profoundly enhancing its capabilities and expanding its applications. The integration of AI within cloud platforms has led to more sophisticated data analysis, automation, and machine learning applications. Companies like Amazon Web Services (AWS) are at the forefront of this integration, heavily investing in AI to expand their service offerings and drive innovation.\nAdvanced AI Capabilities: AWS has been leveraging AI to enhance its cloud offerings. The collaboration between AWS and Nvidia exemplifies this synergy, focusing on providing enterprises with advanced AI capabilities. Their partnership aims to advance AI for large language models, digital biology, climate simulations, and more. This includes the development of Project Ceiba, a supercomputer integrated with AWS services, which utilizes AWS’s Virtual Private Cloud encrypted networking and high-performance block storage.\nGenerative AI Tools: Another significant development is the integration of Nvidia\u0026rsquo;s NeMo Retriever microservice into AWS, which enhances the development of generative AI tools like chatbots and summarization tools. Additionally, Nvidia BioNeMo, available on Amazon SageMaker and AWS’s Nvidia DGX Cloud, simplifies and accelerates the training of AI models for pharmaceutical companies, thereby expediting the drug discovery process.\nAmazon\u0026rsquo;s \u0026ldquo;AI Ready\u0026rdquo; Initiative Amazon\u0026rsquo;s \u0026ldquo;AI Ready\u0026rdquo; initiative underscores the importance of AI skills in the modern workforce. This ambitious program aims to train 2 million individuals in AI skills by mid-decade. It includes free courses for both technical and non-technical audiences and scholarships for students focusing on generative AI. Such initiatives are critical in addressing the growing demand for AI expertise and ensuring that the workforce is prepared for an AI-driven future.\nThe \u0026ldquo;AI Ready\u0026rdquo; initiative involves comprehensive training programs designed for various learning needs. These programs include courses for business and non-technical audiences, developer and technical audiences, and specific training for students. By partnering with educational institutions and organizations, Amazon aims to provide accessible AI education, fostering a broader understanding and adoption of AI technologies across industries.\nTechnical Advancements and Trends The cloud computing market is continually evolving, with several technical advancements shaping its future:\nEdge Computing: This technology processes data closer to its source, reducing latency and bandwidth usage. Edge computing is critical for real-time applications and Internet of Things (IoT) devices, where rapid data processing is essential. By bringing computation and data storage closer to the location where it is needed, edge computing enhances the efficiency and speed of data processing.\nServerless Computing: Serverless computing allows developers to run code without managing servers. It automatically scales with demand, simplifying the development process and reducing operational overhead. AWS Lambda and Google Cloud Functions are prominent examples of serverless platforms. Serverless computing enables developers to focus on writing code and building applications without worrying about the underlying infrastructure, thereby accelerating the development cycle.\nMulti-Cloud Strategies: Businesses are increasingly adopting multi-cloud strategies to avoid vendor lock-in and optimize performance. By leveraging services from multiple cloud providers, organizations can enhance reliability, distribute workloads efficiently, and take advantage of the best features offered by each provider. Multi-cloud strategies also provide greater flexibility in managing and scaling resources, ensuring that businesses can respond quickly to changing demands.\nConclusion The cloud computing market is on a robust growth trajectory, with AI playing a pivotal role in its expansion. The integration of AI with cloud services is driving innovation, enabling advanced data processing and automation, and creating new opportunities for businesses. As cloud providers continue to develop and integrate AI technologies, the capabilities of cloud platforms will continue to expand, offering businesses enhanced tools for innovation and growth.\n","permalink":"/blog/posts/cloud-computing-market-trend-ai/","summary":"The cloud computing market is experiencing rapid growth, driven by technological advancements and the increasing demand for scalable and efficient IT solutions. With a projected CAGR of 14.1% from 2023 to 2030, this expansion is fueled by the integration of artificial intelligence (AI) within cloud platforms, enhancing capabilities in data analysis, automation, and machine learning applications. Companies like Amazon Web Services (AWS) are at the forefront, leveraging AI to drive innovation and expand their service offerings. As AI becomes more integral to cloud computing, businesses are better equipped to navigate the digital landscape, fostering operational efficiency and opening new avenues for growth and development.","title":"The Growth and Evolution of the Cloud Computing Market"},{"content":"Cloud computing represents a paradigm shift in IT infrastructure, enabling scalable and flexible resource management. It encompasses various services like storage, computing power, and networking, delivered over the internet, thus eliminating the need for on-premises hardware.\nCloud computing has revolutionized the way businesses manage IT resources. By offering scalable and flexible solutions over the internet, it has eliminated the need for traditional on-premises hardware, transforming how companies operate and innovate.\nKey Service Models Cloud computing offers three primary service models that cater to different business needs:\nInfrastructure as a Service (IaaS) provides virtualized computing resources over the internet. This model allows businesses to rent servers, storage, and networking infrastructure on a pay-as-you-go basis. Key examples include Amazon Web Services (AWS) EC2, Google Compute Engine, and Microsoft Azure.\nPlatform as a Service (PaaS) delivers hardware and software tools over the internet, primarily for application development. This model enables developers to build, test, and deploy applications without worrying about the underlying infrastructure. Key examples include Google App Engine and Microsoft Azure App Services.\nSoftware as a Service (SaaS) offers software applications over the internet, accessible through web browsers. This model eliminates the need for local installation and maintenance, providing easy access to software on a subscription basis. Popular examples include Salesforce, Google Workspace, and Microsoft 365.\nDeployment Models There are three main cloud deployment models, each suited to different business needs:\nPublic Cloud services are delivered over the internet and shared across multiple organizations. This model offers scalability and cost-efficiency, making it ideal for businesses with fluctuating demands. Key providers include AWS, Google Cloud, and Microsoft Azure.\nPrivate Cloud is dedicated to a single organization, offering enhanced security and control over data and applications. This model is suitable for enterprises with stringent regulatory and security requirements, such as financial institutions and healthcare organizations.\nHybrid Cloud combines public and private clouds, allowing data and applications to be shared between them. This model provides flexibility and optimized workload management, balancing cost efficiency with security. It offers seamless integration and improved data management.\nTechnical Benefits Cloud computing provides several technical advantages that make it an attractive option for businesses:\nScalability: Cloud computing allows businesses to scale resources up or down based on demand. This dynamic scalability ensures optimal resource utilization and cost management.\nDisaster Recovery: Cloud services offer robust disaster recovery solutions, ensuring data backup and rapid recovery in case of outages or data loss. This minimizes downtime and enhances business continuity.\nCost Efficiency: By reducing the need for on-premises hardware and maintenance, cloud computing significantly lowers operational costs. The pay-as-you-go pricing model aligns expenses with actual usage, further optimizing cost efficiency.\nPerformance: Cloud providers utilize a vast network of data centers to deliver high-performance services. This reduces latency, enhances application performance, and improves user experience.\nSecurity: Leading cloud providers implement advanced security measures, including encryption, identity management, and compliance with industry standards. This ensures the protection of sensitive data and applications.\nEmerging Trends Several emerging trends are shaping the future of cloud computing:\nEdge Computing: Edge computing processes data closer to its source, reducing latency and bandwidth usage. This trend is crucial for real-time applications and Internet of Things (IoT) devices.\nServerless Computing: Serverless computing allows developers to run code without provisioning or managing servers. This model automatically scales with demand and simplifies the development process, making it ideal for microservices and event-driven applications.\nAI and Machine Learning Integration: Cloud platforms are increasingly integrating AI and machine learning capabilities. These advanced tools enhance data analysis, automate processes, and enable the development of intelligent applications.\nMulti-Cloud Strategies: Multi-cloud strategies involve using services from multiple cloud providers. This approach avoids vendor lock-in, optimizes performance, and enhances reliability by distributing workloads across different platforms.\nConclusion ","permalink":"/blog/posts/undertanding-cloud-computing/","summary":"Cloud computing revolutionizes IT infrastructure by providing scalable and flexible resources over the internet. This approach eliminates the need for traditional on-premises hardware, offering services such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS), and Software as a Service (SaaS). These models enable dynamic scalability, cost efficiency, and robust security, supporting businesses in efficient resource management and innovation. Emerging trends like edge computing, serverless architectures, and AI integration highlight the evolving landscape, ensuring cloud computing remains integral to modern technology infrastructure.","title":"Understanding Cloud Computing"},{"content":"In the rapidly evolving tech landscape, cloud computing emerges as a pivotal force transforming business infrastructure and operations. Recognized for its scalability and cost-efficiency, cloud computing has become integral to the strategic planning and competitive positioning of modern organizations.\nAs an innovator in the tech industry, it is crucial to harness cloud computing\u0026rsquo;s potential to remain competitive. Transitioning to the cloud offers businesses myriad benefits, including increased operational flexibility, reduced IT maintenance costs, and enhanced security measures. This technical examination will delve into how cloud computing can catalyze business growth and operational efficiency.\nAdvantages of Cloud Computing for Businesses\nCloud computing provides significant cost savings by allowing companies to forego the capital expense of buying hardware and software. The pay-as-you-go service model shifts capital expenditure to operational expenditure, which is more scalable and manageable. This shift not only helps in resource allocation but also frees up capital for other strategic investments.\nScalability is another profound advantage. Cloud environments allow businesses to scale their operations seamlessly without the physical constraints of server capacity. Additionally, the operational agility offered by cloud solutions enables businesses to respond swiftly to market changes and consumer demands by adjusting resource levels as needed.\nCollaboration and accessibility enhancements are also significant; cloud services facilitate improved teamwork and productivity by enabling real-time collaboration across various locations. The ability to access data and systems from anywhere at any time allows businesses to be more agile and responsive.\nKey Technical Aspects of Cloud Computing\nCloud computing incorporates essential elements such as virtualization, automation, and orchestration. Virtualization technology abstracts physical hardware, allowing for more efficient resource utilization and easier scalability. Automation reduces manual handling by automating repetitive tasks, thereby minimizing the risk of human errors and increasing operational efficiency. Orchestration manages complex workflows and services across various cloud environments, optimizing performance and resource usage.\nCloud Computing Models: Public, Private, and Hybrid\nThe choice between public, private, and hybrid cloud models depends on business needs, security requirements, and compliance considerations. The public cloud offers cost efficiency and scalability, suitable for companies without intensive compliance demands. In contrast, the private cloud provides more control and security, ideal for businesses with strict data protection standards. The hybrid cloud model offers a balanced solution that utilizes both public and private clouds according to different workload requirements, providing flexibility and scalability while ensuring data security.\nSecurity and Compliance in Cloud Computing\nSecurity remains a top priority in cloud computing. Providers invest heavily in security technologies such as encryption, intrusion detection systems, and comprehensive compliance frameworks to protect sensitive data and ensure privacy. Regular security audits and adherence to strict regulatory standards are necessary to maintain data integrity and confidentiality in cloud environments.\nEfficiency and Innovation through Cloud Solutions\nCloud computing supports business innovation by providing a flexible and scalable infrastructure to test and deploy new applications quickly. This capability allows businesses to experiment with new ideas at a lower risk and cost, supporting faster innovation cycles and continuous improvement.\nSelecting a Cloud Computing Provider\nWhen selecting a provider, businesses must evaluate factors such as reliability, scalability, performance, security, and cost. Service level agreements (SLAs) should meet business requirements for uptime and performance. Security features, compliance with industry standards, and cost structures also play crucial roles in the selection process.\nConclusion: Empowering Business Growth through Cloud Technology\n","permalink":"/blog/posts/impact-cloud-on-entr/","summary":"Cloud computing incorporates essential elements such as virtualization, automation, and orchestration. Virtualization technology abstracts physical hardware, allowing for more efficient resource utilization and easier scalability. Automation minimizes the risk of human errors and increases operational efficiency by automating repetitive tasks. Orchestration manages complex workflows and services across various cloud environments, optimizing performance and resource usage. Together, these technologies enable businesses to adapt swiftly to market demands and scale operations efficiently.","title":"The Strategic Impact of Cloud Computing on Modern Business Infrastructure"},{"content":"Discover the cutting-edge intersection of Serverless WebAssembly that is revolutionizing web application development. This article delves deep into how WebAssembly (Wasm), when paired with serverless computing paradigms, is reshaping the development landscape by offering unmatched efficiency, scalability, and performance.\nServerless WebAssembly allows developers to transcend traditional server-based limitations by deploying code directly at the edge. This shift eliminates the need for conventional servers, thereby reducing latency, enhancing user experiences, and yielding significant cost reductions. The technology is inherently language-agnostic, empowering developers to use preferred programming languages and frameworks. This versatility, along with the ability to integrate pre-existing modules and libraries, significantly accelerates the development of intricate and feature-rich web applications.\nThis exploration not only uncovers the transformative capabilities of Serverless WebAssembly but also highlights its potential to redefine web application development paradigms. Get ready to harness the power of this advanced technology and elevate your web applications to unprecedented levels.\nServerless Architecture: Core Benefits and Operational Insights\nServerless architecture offers a unique cloud computing model where infrastructure management is handled by the cloud provider, freeing developers from server provisioning and management tasks. This model is inherently cost-effective, utilizing a pay-as-you-go approach that optimizes resource usage by activating them only during code execution. Such architectures excel in scalability, automatically adjusting resource allocation in response to real-time demand to maintain performance during peak loads.\nThe primary advantages of serverless computing include diminished operational overhead, amplified scalability, and enhanced developer productivity. The abstraction of the infrastructure layer allows developers to focus primarily on coding and direct value creation for end-users. Additionally, the architecture promotes event-driven programming, enabling applications to become more modular and decoupled.\nServerless is particularly advantageous for applications experiencing variable workloads. It efficiently manages dynamic resource allocation, enabling seamless handling of fluctuating traffic without incurring excess costs. This capability is essential for contemporary web applications that require the agility to scale promptly and economically.\nDeep Dive into Serverless WebAssembly Mechanisms\nServerless WebAssembly integrates the scalability of serverless architecture with the robust performance capabilities of WebAssembly. Developers can write code in languages that are compiled to WebAssembly—such as Rust, C, or AssemblyScript—and deploy these directly to a serverless environment. This environment is responsible for executing the code securely and efficiently, without the overhead associated with traditional server management.\nWhen a request triggers a Serverless WebAssembly function, the platform promptly loads and executes the WebAssembly module. This on-demand, efficient execution model ensures that resources are allocated only when necessary. WebAssembly\u0026rsquo;s portable and lightweight nature contributes to rapid startup times and minimal latency, making it ideal for performance-sensitive applications.\nThis innovative approach leverages WebAssembly’s benefits—like near-native execution speed and platform independence—while embracing the scalability and cost-efficiency of serverless architectures. The result is a potent framework for building web applications that are not only fast and responsive but also economically and operationally efficient.\nStrategic Advantages of Integrating WebAssembly with Serverless Frameworks\nThe fusion of WebAssembly with serverless frameworks substantially boosts application responsiveness and developer agility. WebAssembly modules execute at speeds comparable to native applications, significantly enhancing performance over traditional JavaScript-based solutions. This capability is crucial for applications requiring intensive computation, such as image processing or complex numerical simulations.\nThe inclusive development ecosystem supported by Serverless WebAssembly encourages a diverse array of programming languages and tools, enriching the development process. This flexibility allows development teams to select the optimal tools for specific tasks, enhancing both product quality and innovation potential.\nMoreover, this integration fosters a sustainable operational model by optimizing resource utilization and reducing the requisite for perpetual server operation, which aligns with contemporary green computing initiatives.\nConclusion: Pioneering Web Development with Serverless WebAssembly\n","permalink":"/blog/posts/serverless-wasm-better-web/","summary":"Serverless WebAssembly integrates the robust performance of WebAssembly with the scalable architecture of serverless environments. Developers can deploy code written in languages like Rust, C, or AssemblyScript directly to a serverless platform. This setup eliminates traditional server management overhead while enhancing security and efficiency. When triggered, the platform loads and executes the WebAssembly module on-demand, ensuring that resources are utilized only when necessary. This leads to rapid startup times, reduced latency, and optimizes performance for critical applications, making Serverless WebAssembly an ideal choice for developing modern, high-performance web applications.","title":"Empowering Scalable and Efficient Web Applications With Serverless WebAssembly"},{"content":"The digital transformation of businesses has significantly increased the reliance on advanced computing paradigms, primarily cloud computing and distributed computing. While these terms are often used interchangeably, they represent distinct approaches with unique advantages and applications.\nCloud Computing Cloud computing refers to the delivery of various services, including servers, storage, databases, networking, software, and more, over the internet. Cloud providers such as AWS, Google Cloud, and Microsoft Azure offer these services on a pay-as-you-go basis, allowing businesses to scale resources dynamically based on demand. The centralization of resources in data centers provides high availability, reliability, and ease of management. Key benefits include cost-efficiency, as users only pay for what they use, and the ability to access services from anywhere with an internet connection.\nHowever, cloud computing comes with certain drawbacks. Issues such as vendor lock-in, where transitioning between providers can be challenging, and limited control over infrastructure since the cloud provider manages the hardware and software, can pose significant challenges. Additionally, the dependence on internet connectivity can be a limitation in areas with poor network access.\nDistributed Computing Distributed computing involves a network of autonomous computers working together to solve complex problems or perform large-scale computations. These systems share resources, and tasks are divided among multiple machines to improve processing speed and fault tolerance. Distributed computing is widely used in applications requiring massive parallel processing capabilities, such as scientific simulations and large-scale data analysis.\nThis approach provides significant advantages in terms of scalability and fault tolerance. By distributing tasks, it reduces the time required to solve problems and improves the system\u0026rsquo;s resilience to failures. However, it also introduces complexity in terms of system design, maintenance, and data consistency. Managing a distributed system requires sophisticated software to handle communication, synchronization, and security across multiple nodes.\nComparative Analysis Both cloud computing and distributed computing offer scalability, but they achieve it differently. Cloud computing uses elasticity, allowing resources to be scaled up or down based on demand, which is particularly beneficial for businesses with variable workloads. Distributed computing achieves scalability by distributing tasks across multiple machines, enhancing processing efficiency and fault tolerance.\nReliability is another key consideration. Cloud computing relies on redundant infrastructure and data replication to ensure high availability. Distributed computing, while also fault-tolerant, depends on the design and implementation of fault detection and data replication mechanisms to maintain reliability.\nFrom a cost perspective, cloud computing follows a pay-as-you-go model, eliminating the need for significant upfront investments in infrastructure. Distributed computing, however, may require substantial initial investment in hardware and network infrastructure but can be more cost-effective in the long run for persistent and intensive workloads.\nHere is a comparative table highlighting the key differences between cloud computing and distributed computing:\nAttribute Cloud Computing Distributed Computing Definition Delivery of computing services over the internet Use of multiple computers to solve a problem or perform a task Resource Sharing Resources shared among multiple users and applications Resources shared among multiple computers in a network Scalability Easy scalability via elasticity Scalable with careful design and coordination Location Hosted in data centers located in various geographical locations Performed on local networks or across multiple dispersed locations Cost Pay-as-you-go model Upfront costs for setup and maintenance Reliability High reliability with redundancy and failover mechanisms Depends on design and fault-tolerance measures Centralization Centralized data centers for resource provisioning and management Distributed processing and data across multiple nodes Security Managed by cloud providers with robust security measures Requires organization-managed security measures Integration of AI and Future Trends The integration of artificial intelligence (AI) into cloud computing platforms has further driven their adoption. AI enhances cloud capabilities by enabling advanced data analysis, automation, and machine learning applications. Companies like AWS are leading the charge by embedding AI services into their cloud offerings, providing tools for natural language processing, computer vision, and predictive analytics.\nDistributed cloud computing is emerging as a hybrid approach, combining elements of both paradigms. This model allows data and applications to be distributed across multiple cloud environments while maintaining centralized management and control. It offers the benefits of reduced latency, improved performance, and enhanced security by bringing computing resources closer to the end-users.\nConclusion Choosing between cloud computing and distributed computing depends on the specific needs and goals of an organization. Cloud computing is ideal for businesses seeking flexibility, ease of management, and cost efficiency. In contrast, distributed computing is better suited for applications requiring high performance, scalability, and resilience to failures.\n","permalink":"/blog/posts/dist-vs-cloud-computing/","summary":"The digital transformation of businesses has significantly increased reliance on advanced computing paradigms, primarily cloud computing and distributed computing. Cloud computing offers scalable, on-demand access to computing resources over the internet, managed centrally by providers like AWS and Google Cloud. In contrast, distributed computing involves a network of interconnected computers working collaboratively to solve complex problems, enhancing fault tolerance and processing speed. While cloud computing excels in flexibility and cost-efficiency with a pay-as-you-go model, distributed computing provides superior performance for parallel processing tasks. The integration of AI into cloud platforms further enhances capabilities, driving innovation and efficiency in various applications.","title":"Differences Between Cloud Computing and Distributed Computing"},{"content":"As the digital landscape evolves, the integration of WebAssembly (Wasm) with serverless architectures is transforming the way developers create scalable and efficient web applications. A recent IDC report highlights the advancements in WebAssembly PaaS and its significant impact on AI-driven development.\nKey Developments in WebAssembly PaaS Serverless AI Integration\nRapid Start-Up Times: New WebAssembly PaaS solutions boast cold start-up times that are 100x faster than traditional methods, reducing execution time from minutes to under a second. This enhancement allows for concurrent execution of hundreds of applications, optimizing performance and resource use. AI Capabilities: These platforms support AI inferencing with large language models (LLMs) such as Llama2 and Code Llama. Features include sentence embeddings, vector-ready databases, key/value storage, and full-stack serverless application support, offering a comprehensive environment for AI application development. NoOps Approach\nLocal and Cloud Consistency: Developers experience the same environment locally as in the cloud, simplifying the development process and reducing the operational overhead typically associated with database management. Enhanced Productivity: By automating database provisioning and management, these platforms allow developers to focus on coding rather than infrastructure, leading to increased efficiency and faster time-to-market. Strategic Advantages Improved Developer Experience\nSeamless Deployment: The platforms offer a smooth transition from local development to cloud deployment, minimizing context switching and operational distractions. Event-Driven Architecture: These solutions promote modular and decoupled application design, enhancing scalability and maintainability. Scalability and Cost Efficiency\nDynamic Resource Allocation: Resources are allocated based on real-time demand, ensuring optimal performance during traffic spikes and reducing costs during low-usage periods. Economical Model: The pay-as-you-go pricing structure aligns resource usage with operational costs, offering a cost-effective alternative to traditional server-based models. Market Position and Future Directions Competitive Landscape\nInnovation Leadership: WebAssembly PaaS platforms are emerging as leaders by addressing challenges that hinder serverless adoption, such as operational complexities and startup times. AI Integration: The focus on AI inferencing capabilities is positioning these platforms to meet the growing demand for AI-driven applications, making them essential tools for modern developers. Future Prospects\nBroadening Application Support: Future developments aim to extend support to existing applications, including Java and .NET monoliths, by converting them into Wasm components without requiring extensive code rewrites. Sustainability: Efficient resource utilization and reduced execution times also contribute to lower carbon footprints, aligning with green computing initiatives. Conclusion ","permalink":"/blog/posts/wasm-paas-idc/","summary":"WebAssembly PaaS is revolutionizing web application development by integrating Wasm with serverless architectures. According to an IDC report, these platforms achieve 100x faster cold start-up times, enabling concurrent execution of multiple applications and optimizing resource use. They support AI inferencing with models like Llama2, providing features such as sentence embeddings, vector-ready databases, and full-stack serverless support. By offering a consistent local and cloud development experience, these solutions enhance developer productivity and streamline database management, leading to faster time-to-market and cost efficiency. As the market evolves, WebAssembly PaaS platforms are set to redefine the future of scalable and efficient web applications.","title":"WebAssembly PaaS - A New Frontier in an AI-First World"},{"content":"As the era of Moore\u0026rsquo;s Law comes to a close, the computing industry faces significant challenges. The traditional method of doubling transistors on integrated circuits every two years is reaching its physical and economic limits. According to the paper \u0026ldquo;There’s Plenty of Room at the Top: What Will Drive Computer Performance after Moore’s Law?\u0026rdquo; by Charles E. Leiserson et al., future performance gains must come from innovations in software, algorithms, and hardware architecture—the \u0026ldquo;Top\u0026rdquo; of the computing stack.\nWebAssembly (Wasm): Addressing Post-Moore\u0026rsquo;s Law Challenges WebAssembly (Wasm) is a binary instruction format designed for stack-based virtual machines, providing a portable compilation target for high-level languages like C, C++, and Rust. Its design principles make it a powerful tool for tackling the new performance challenges.\nPerformance and Efficiency WebAssembly executes code at near-native speed by utilizing Just-In-Time (JIT) compilation and modern CPU features. Here’s how it addresses key performance issues:\nCompact Binary Format: Wasm\u0026rsquo;s binary format is optimized for size and load time, reducing the overhead associated with higher-level language abstractions. This directly combats software bloat, a significant inefficiency highlighted in Leiserson et al.\u0026rsquo;s paper. Efficient Execution Model: WebAssembly is designed to minimize execution time by taking advantage of modern hardware features such as parallelism and SIMD (Single Instruction, Multiple Data) instructions. This makes Wasm ideal for performance-critical applications where every millisecond counts. Portability WebAssembly’s runtime environment is supported by all major web browsers and can be embedded in various platforms. This ensures that performance optimizations are not hardware-specific, providing consistent, high-performance execution across different systems:\nCross-Platform Compatibility: Wasm\u0026rsquo;s universal runtime allows developers to write code once and run it anywhere, eliminating the need for platform-specific optimizations. This broadens the reach of performance enhancements and simplifies deployment. Security WebAssembly’s execution within a secure sandbox isolates it from the host system, mitigating security risks while maintaining high performance:\nSandboxed Execution: Wasm’s isolation model is crucial for running untrusted code safely, especially in web environments where security is paramount. This model ensures that malicious code cannot compromise the host system, providing a secure execution environment. Modularity and Extensibility WebAssembly’s modular design supports the creation and integration of highly optimized components:\nModular Architecture: Wasm modules can be developed, tested, and deployed independently, facilitating the construction of large, reusable system components. This modularity is essential for achieving performance gains in complex systems, as discussed in the paper. Practical Applications and Impact WebAssembly is already demonstrating its potential across various domains:\nWeb Applications: Applications like AutoCAD and Figma leverage WebAssembly to deliver high-performance experiences directly in the browser, demonstrating Wasm’s capability to handle intensive tasks traditionally reserved for native applications. Edge Computing: Wasm’s lightweight and secure execution model makes it ideal for edge computing scenarios, where performance and security are critical. It enables efficient processing at the edge, reducing latency and bandwidth usage. Cloud Services: Cloud providers are incorporating WebAssembly for serverless computing and microservices, capitalizing on its performance and security benefits to enhance cloud infrastructure efficiency and reliability. Conclusion As Moore\u0026rsquo;s Law reaches its limits, performance improvements will increasingly come from optimizing the \u0026ldquo;Top\u0026rdquo; of the computing stack—software, algorithms, and hardware architecture. WebAssembly emerges as a crucial technology in this landscape, offering high efficiency, cross-platform compatibility, enhanced security, and modularity. By embracing WebAssembly, developers can effectively address the performance challenges of the post-Moore era, ensuring continued innovation and efficiency.\nFor a deeper understanding of the challenges and opportunities in this new era, refer to the paper by Charles E. Leiserson et al., \u0026ldquo;There’s Plenty of Room at the Top: What Will Drive Computer Performance after Moore’s Law?\u0026rdquo;.\n","permalink":"/blog/posts/wasm-moore-law/","summary":"As Moore\u0026rsquo;s Law slows, performance gains must come from optimizing the \u0026ldquo;Top\u0026rdquo; of the computing stack—software, algorithms, and hardware architecture. WebAssembly (Wasm) is a key technology in this shift. Its compact binary format and near-native execution speed reduce software bloat, enhancing efficiency. Wasm\u0026rsquo;s universal runtime environment ensures cross-platform compatibility, while its secure sandboxing provides robust security. Additionally, its modular design fosters the development of high-performance components. WebAssembly addresses the critical performance challenges.","title":"Embracing WebAssembly for Post-Moore's Law Performance Challenges"},{"content":"In the realm of software infrastructure, there exists a clear demarcation: platforms that are developer-centric and self-serving, and those that are not. This distinction is what sets apart industry leaders, including both established hyperscalers and companies like Cloudflare, Fastly, Vercel, \u0026amp; Netlify. While challenging the dominance of hyperscalers might seem daunting, competing effectively against the likes of Cloudflare and its peers is not only feasible but within reach. The reason? You likely possess the hardware—potentially superior and more geographically diverse than theirs. The key ingredient missing is a developer-friendly, self-serving platform. Traditionally, crafting such a platform demanded years and significant investment in skilled engineering talent. However, I\u0026rsquo;m here to guide you through an alternative pathway that can swiftly bring you online and ensure production readiness.\nAs the founder of Taubyte, I am driven by the vision to democratize cloud computing, making it as accessible as possible. Achieving this vision entails developing infrastructure software that\u0026rsquo;s easy to deploy and maintain. An added bonus in our approach is our commitment to preventing vendor lock-in; hence, our core technology is open-sourced. Our mission is not just about providing tools but ensuring that these tools are readily accessible, ensuring freedom and flexibility for developers everywhere.\nTruly a No-Brainer to Build a Cloud! Observing the technological fortresses erected by Fastly, Vercel, Cloudflare, and others can indeed be daunting. They\u0026rsquo;ve amassed vast codebases and teams of skilled engineers dedicated to constant improvement and maintenance. However, the sheer size of their infrastructure also presents a significant challenge—it\u0026rsquo;s not easy to pivot quickly or innovate in ways that might render their existing systems obsolete due to internal inertia.\nEnter the simplest incarnation of a Taubyte Cloud, we call dreamland, which runs directly on your computer.\nStart by installing it with the following command:\n$ npm i @taubyte/dream With the dream command-line tool now at your disposal, let\u0026rsquo;s initiate your personal cloud:\n$ dream new multiverse [INFO] Dreamland ready [SUCCESS] Universe blackhole started! Any ERROR messages related to seer can be disregarded at this stage.\nThe SUCCESS notification confirms the operational status of your cloud. Proceed by navigating to console.taubyte.com and selecting the Dreamland button to interact with your new cloud environment. This button becomes interactive only when Dreamland is detected.\nNext steps involve the web console\u0026rsquo;s sidebar: (1) select Network, followed by (2) blackhole. Shortly, you\u0026rsquo;ll be presented with a view resembling the following: What you\u0026rsquo;re witnessing is a constellation of virtual nodes, together forming a Cloud Computing Platform. This platform is equipped for serverless computing, web hosting, storage solutions, databases, pub-sub mechanisms, and much more.\nRemarkably, this cloud is immediately available for developer engagement, accessible either via the command-line or the Web Console.\nFor an in-depth exploration of Dreamland and the Web Console, I recommend delving into the Introduction to Taubyte, an essential read.\nPick a Domain Every Taubyte Cloud is associated with a Fully Qualified Domain Name (FQDN). Essentially, you can use any domain or sub-domain that you control. For instance, I\u0026rsquo;ve chosen enterprise.starships.ws for Starship Enterprise\u0026rsquo;s Web Services.\nDevelopers often require a temporary sub-domain for testing purposes. You\u0026rsquo;re free to use a sub-domain of your main domain or opt for an entirely different one. While g.enterprise.starships.ws or el.starships.ws are valid options, my passion for Sci-Fi inspires me to select e.ftll.ink (Enterprise\u0026rsquo;s Faster Than Light Link).\nGet Your Infrastructure Ready The choice of infrastructure is yours to make. The only requirement is hosts (either bare metal or VMs) running Ubuntu 22.04. While any number of hosts can work, I recommend starting with three, each equipped with:\nA public IP +8GB of RAM For demonstration purposes, I quickly provisioned 3 VMs across various locations:\nName Location IP host-001-enterprise-starships-ws Iowa 34.133.173.124 host-002-enterprise-starships-ws Toronto 34.130.131.76 host-003-enterprise-starships-ws Los Angeles 35.235.122.141 Note: This cloud setup is temporary and will eventually be decommissioned. However, it will remain accessible for testing by developers for as long as it\u0026rsquo;s operational.\nFirewall Configuration Ensure the following ports are open to facilitate communication and service delivery:\nPorts Protocols Description 4242, 4247, 4252 TCP For Peer-to-peer communication and IPFS. 80, 443 TCP For HTTP and HTTPS - serving APIs and hosted resources. 53, 953 TCP, UDP For DNS resolution. Preparing the Hosts Before proceeding with the tau installation on the hosts, a few preliminary steps are required:\nInstalling curl \u0026amp; vim Ensure curl and vim (or your preferred text editor) are installed:\n$ sudo apt update $ sudo apt install curl vim If you\u0026rsquo;re unfamiliar with vim, consider trying vim-adventures for a fun introduction.\nFreeing Up DNS Ports To allow the seer protocol to operate correctly, DNS settings need adjustment:\n$ sudo vim /etc/systemd/resolved.conf In edit mode (:i), configure:\nDNS=1.1.1.1 DNSStubListener=no Then, apply the changes:\n$ sudo systemctl restart systemd-resolved.service $ sudo ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf Docker Installation Execute the following to install Docker:\n$ curl -fsSL https://get.docker.com | sh Setting Up the First Host The initial host, in this scenario host-001-enterprise-starships-ws, will serve as the cornerstone for generating our network\u0026rsquo;s secrets.\nInstalling Tau The installation of the tau software is straightforward. Execute the command below:\n$ curl https://get.tau.link/tau | sh It\u0026rsquo;s worth noting that a single host can support multiple nodes, provided their ports do not overlap. However, for the purposes of this guide, we will maintain a one-node-per-host configuration.\nUpon successful installation, you should see an output similar to the following:\n% Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 3982 100 3982 0 0 3962 0 0:00:01 0:00:01 --:--:-- 3966 Downloading release: v1.1.2 From: https://github.com/taubyte/tau/releases/download/v1.1.2/tau_1.1.2_linux_amd64.tar.gz ######################################################################## 100.0% Installation complete This signifies that tau has been successfully installed and is ready for configuration and use.\nConfiguring Your Node The configuration process for a node is straightforward and can be executed with a single command:\n$ sudo tau config generate -n enterprise.starships.ws \\ -s compute --protos all --ip 34.133.173.124 \\ --dv --swarm Here\u0026rsquo;s a quick rundown of the options used:\n-n specifies the domain name (or network name) for the node. -s assigns a name to this configuration, often referred to as a \u0026ldquo;shape.\u0026rdquo; --protos all activates all available protocols. --ip indicates the IP address the node should use for announcements. --dv generates a domain validation key pair. --swarm creates a swarm key for network clustering. Note: It\u0026rsquo;s generally not advisable to enable all protocols on a single node due to potential conflicts and resource constraints. This article simplifies the setup for demonstration purposes. Adjustments to the protocol configuration can easily be made with a single command, which we will explore in future discussions.\nUpon successful configuration, you\u0026rsquo;ll receive the node\u0026rsquo;s ID as confirmation:\n[INFO] ID: 12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY Fine-tuning the Configuration With the basic configuration in place, some adjustments are necessary for optimal performance and alignment with your specific requirements:\n$ sudo vi /tb/config/compute.yaml For instance, you might want to update the generated domain to match your preferred domain. In this example, I\u0026rsquo;ll use e.ftll.ink:\ngenerated: e.ftll.ink Additionally, since the gateway and substrate protocols cannot coexist on the same node, we\u0026rsquo;ll remove the gateway protocol from our list. The revised configuration should look something like this:\nprivatekey: \u0026lt;redacted\u0026gt; swarmkey: keys/swarm.key protocols: - auth - patrick - monkey - tns - hoarder - substrate - seer p2p-listen: - /ip4/0.0.0.0/tcp/4242 p2p-announce: - /ip4/34.133.173.124/tcp/4242 ports: main: 4242 lite: 4247 ipfs: 4252 location: lat: 40.076897 long: -109.33771 network-fqdn: enterprise.starships.ws domains: key: private: keys/dv_private.pem public: keys/dv_public.pem generated: e.ftll.ink plugins: {} Should the location be inaccurately determined, you have the option to correct it manually. The final step involves validating the configuration to ensure its accuracy and completeness:\n$ sudo tau conf validate -s compute A lack of error messages signifies that your configuration is correct.\nManually Starting the Node To initiate the node manually, execute the following command:\n$ sudo tau start -s compute Next, verify that your node is active and accessible. Open your web browser and navigate to slimdig.com. There, you\u0026rsquo;ll perform a simple check: (1) input seer.tau.\u0026lt;your domain\u0026gt;, (2) enter your server\u0026rsquo;s public IP, and (3) click on the A button. Seeing your server\u0026rsquo;s IP address as a return verifies that your node is live and operational.\nTransitioning to a Systemd Service For a more resilient setup, converting the manually started service into a systemd service ensures that it will automatically restart upon failure or server reboot.\nFirst, halt the currently running service by using CTRL-C. Then, proceed to create a systemd service file:\n$ sudo vim /lib/systemd/system/tau@.service Incorporate the following configuration into your systemd service file:\n[Unit] Description=Taubyte Tau Service Running %i [Service] Type=simple ExecStart=/tb/bin/tau start -s %i StandardOutput=journal User=root Group=root LimitAS=infinity LimitRSS=infinity LimitCORE=infinity LimitNOFILE=65536 Restart=always RestartSec=1 [Install] WantedBy=multi-user.target After saving the file, enable and initiate the service to ensure it starts automatically:\n$ sudo systemctl enable tau@compute $ sudo systemctl start tau@compute To confirm the service is running as expected, check its status:\n$ sudo systemctl status tau@compute You should see output similar to the following, indicating that the tau@compute service is active and running:\n● tau@compute.service - Taubyte Tau Service Running compute Loaded: loaded (/lib/systemd/system/tau@.service; enabled; vendor preset: enabled) Active: active (running) since Fri 2024-02-09 22:43:52 UTC; 1min 5s ago Main PID: 4588 (tau) Tasks: 14 (limit: 38492) Memory: 202.0M CPU: 53.521s CGroup: /system.slice/system-tau.slice/tau@compute.service └─4588 /tb/bin/tau start -s compute Feb 09 22:43:52 host-001-enterprise-starships-ws systemd[1]: Started Taubyte Tau Service Running compute. This service configuration ensures your node remains operational across restarts and system updates, providing a stable and reliable infrastructure component.\nConfiguring DNS for Load Balancing The Seer protocol plays a crucial role in DNS load balancing within the Taubyte ecosystem, enabling protocol translation into valid IP addresses using the \u0026lt;protocol\u0026gt;.tau.\u0026lt;domain\u0026gt; convention. This powerful feature allows for efficient load balancing across a Taubyte-based cloud with just a simple CNAME (or ALIAS, for DNS providers that support it) record.\nDelegating the tau Subdomain To leverage this capability, it\u0026rsquo;s necessary to delegate the tau subdomain to the nodes running the Seer protocol within your cloud. Here\u0026rsquo;s how you can do this with your DNS provider; the example below uses Namecheap for the domain starships.ws:\nAdding the Node as an A Record:\nSelect the A record type. Name it (in this case, seer.\u0026lt;domain\u0026gt;). Enter the IP address of the node. Confirm by validating the entry. Delegating with an NS Record:\nChoose the NS record type for delegation. Label it tau.\u0026lt;domain\u0026gt;. Set its value to your chosen name (e.g., seer.\u0026lt;domain\u0026gt;). Validate the entry to complete the delegation. Verifying the Configuration To ensure the DNS configuration is effective, use a tool like slimdig:\nEnter \u0026lt;protocol\u0026gt;.tau.\u0026lt;domain\u0026gt; (for this demonstration, tns.tau.enterprise.starships.ws). Ensure the query is set to a public DNS server like 8.8.8.8. Click on the A button to perform the lookup. Keep in mind, DNS propagation can delay the effectiveness of these new entries, requiring multiple attempts over several minutes to verify.\nCongratulations, your cloud is now operational! You can connect to it via tau-cli or the Web Console to deploy frontend interfaces, serverless computing functions, and more. The next steps will involve bringing the remaining two servers online to enhance our cloud\u0026rsquo;s resilience and capacity.\nShadow Clone Jutsu: Cloning the Setup To efficiently replicate our initial setup across two additional hosts, we\u0026rsquo;ll first create a configuration template. This approach ensures consistency, particularly concerning the swarm key and domain validation keys.\nExporting the Configuration Template Initiate the export with the following command, which will encrypt the secrets for added security:\n$ sudo tau config export -s compute --protect You\u0026rsquo;ll be prompted to enter a password for the encryption:\nPassword? Remember this password; it\u0026rsquo;s crucial for the subsequent steps.\nThe exported configuration will resemble the following (omit the location to let it be automatically determined for the other nodes):\norigin: shape: compute host: host-001-enterprise-starships-ws time: 2024-02-12T05:41:25.218338331Z protected: true source: swarmkey: PZuGcV96BbfM...2RE8ZEfR2pZoM29z8 protocols: - auth - patrick - monkey - tns - hoarder - substrate - seer p2p-listen: - /ip4/0.0.0.0/tcp/4242 p2p-announce: - /ip4/34.133.173.124/tcp/4242 ports: main: 4242 lite: 4247 ipfs: 4252 network-fqdn: enterprise.starships.ws domains: key: private: BDN9SEUFsolg...25pUUrUpFxSFhjlCv public: cmS5kmov/cJ9...NezzWwcYVj4YVNOg generated: e.ftll.ink plugins: {} To facilitate the bootstrap process for the additional nodes, retrieve the first node\u0026rsquo;s multi-address:\n$ sudo tau config show -s compute | grep Announce The output should provide the address necessary for peer connections:\n│ P2PAnnounce │ /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY │ In this case, the multi-address is:\n/ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY Preparing the Additional Hosts Establish SSH connections to the remaining two hosts, ensuring they are prepared as described in the Preparing the Hosts section. Transfer the compute.tmpl.yaml template (minus the location) and the systemd service file to each.\nInstalling Tau On each of the new hosts, install tau using the same command as before:\n$ curl https://get.tau.link/tau | sh This step lays the foundation for a streamlined expansion of your Taubyte cloud, leveraging the power of configuration templates and ensuring a uniform setup across your infrastructure.\nConfiguring the Additional Hosts With the template and necessary preparations in place, proceed to configure the additional hosts:\nFor the Second Host: $ sudo tau config gen --ip 34.130.131.76 --use compute.tmpl.yaml --bootstrap /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY - **For the Third Host:** ```sh $ sudo tau config gen --ip 35.235.122.141 --use compute.tmpl.yaml --bootstrap /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY Important considerations:\nUtilize the correct IP addresses for each host. The template\u0026rsquo;s encryption password will be required. Each host is bootstrapped to the initial node, ensuring connectivity and synchronization within the network. Systemd Setup After configuration, ensure the tau service will automatically start on each host:\n$ sudo cp ~/tau@.service /lib/systemd/system/tau@.service $ sudo systemctl enable tau@compute $ sudo systemctl start tau@compute Verify the service status to confirm active running:\n$ sudo systemctl status tau@compute DNS Verification To ensure all nodes are correctly registered and operational, utilize DNS queries:\nEnter \u0026lt;protocol\u0026gt;.tau.\u0026lt;domain\u0026gt; and select A to perform the query. You should observe all three servers listed, indicating successful network integration.\nFinal Adjustments With the cloud infrastructure now horizontally expanded and operational, attention turns to ensuring seamless interaction among all hosts and leveraging their capabilities for DNS load balancing.\nDNS Adjustments For the Main Domain: Additional A records for each new host need to be added to the DNS configuration. Running a DNS lookup should now reflect all active hosts: For the Generated Domain: Delegate the specified subdomain to your cloud by adding the appropriate NS entry, enhancing domain management and flexibility. Bootstrapping for Recovery and Expansion Ensure all nodes are aware of each other to facilitate network resilience and data consistency:\nCollect and share the multi-addresses among all nodes. Update the peers section in each node\u0026rsquo;s configuration to include all peers. Validate the configuration for accuracy. No restart is required as peers are dynamically managed, but ensuring accurate configuration enhances the network\u0026rsquo;s ability to recover and scale effectively.\nConfigure them To extend our cloud\u0026rsquo;s reach, we proceed to configure the additional nodes with precision, ensuring a seamless integration into our existing setup. Execute the following commands on the designated hosts to generate their configurations, employing the compute.tmpl.yaml as a blueprint and leveraging the bootstrap mechanism for network connectivity:\nOn the Second Host:\n$ sudo tau config gen --ip 34.130.131.76 --use compute.tmpl.yaml --bootstrap /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY [INFO] ID: 12D3KooWSJZQAPtVaLuusfr3g71FZEeyxr8HdmPcjKeQonHmQXn2 On the Third Host:\n$ sudo tau config gen --ip 35.235.122.141 --use compute.tmpl.yaml --bootstrap /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY **Important**: Use the correct IP addresses for each host and the first node\u0026#39;s multi-address for initial discovery. You\u0026#39;ll be prompted to enter the password established during the template creation phase—this step is crucial for maintaining security and consistency across your cloud infrastructure. ### Setup systemd To ensure our nodes remain resilient and automatically recover from reboots or unforeseen downtime, we embrace systemd\u0026#39;s robustness. On both nodes, execute the following: ```sh $ sudo cp ~/tau@.service /lib/systemd/system/tau@.service $ sudo systemctl enable tau@compute $ sudo systemctl start tau@compute Verify the service\u0026rsquo;s heartbeat:\n$ sudo systemctl status tau@compute Check with DNS A litmus test for operational integrity, DNS queries reveal the network\u0026rsquo;s pulse. Employ \u0026lt;protocol\u0026gt;.tau.\u0026lt;domain\u0026gt; and observe:\nThe triad of servers, now visible, confirms our cloud\u0026rsquo;s expanded horizon.\nFinal touches With our cloud now stretching across horizons, it\u0026rsquo;s paramount to ensure inter-node discovery and dynamic load balancing. Our next steps solidify the network\u0026rsquo;s backbone, priming it for seamless scalability.\nDNS Main Domain Augmenting our DNS configuration to include all nodes under seer.\u0026lt;domain\u0026gt; enriches our network\u0026rsquo;s resilience:\nA subsequent dig command unfurls the network\u0026rsquo;s canvas, displaying our nodes in unison:\nFor those wielding Linux, dig a seer.enterprise.starships.ws +noall +answer yields an ensemble of IPs, signifying our united front.\nGenerated Domain Recall our s.ftll.ink domain, a digital expanse awaiting its purpose. An NS entry, pointing to our cloud, bestows it with life:\nBootstrapping In the realm of distributed systems, autonomy is king. Ensuring each node can independently find its brethren guarantees our network\u0026rsquo;s resilience. With the multi-addresses of all nodes now known, we weave them into each node\u0026rsquo;s fabric:\npeers: - /ip4/34.133.173.124/tcp/4242/p2p/12D3KooWKv5oNF2a6h9sYzRUPEAaYe6feTbBbcLYZYVFrMDDCHzY - /ip4/34.130.131.76/tcp/4242/p2p/12D3KooWHrp2t9npN2TW4dv47uEvJh6qfs6U2ymhkiVVNpcR3cWE - /ip4/35.235.122.141/tcp/4242/p2p/12D3KooWKQJfLU74VJzsvhAKUJ8KQidBr1CowMo1e1YRrSb2v TZd A final validation ensures our network\u0026rsquo;s readiness to face the digital expanse:\n$ sudo tau config check -s compute No error messages? Then stand back and behold—a cloud, not just built, but crafted, ready to rival the titans.\nRestart? No need for manual restarts. The peer connections are maintained in a persistent database, ensuring that even after recovery or reconfiguration, the nodes automatically recognize each other without intervention.\nLet\u0026rsquo;s Try the Cloud! Congratulations, your very own cloud infrastructure is now operational, poised to compete with giants like Cloudflare, Netlify, Vercel, and Fastly. Let\u0026rsquo;s walk through a hands-on tour to see it in action.\nLogin Procedure Embark on your cloud journey by navigating to console.taubyte.com in your web browser, Chrome recommended for optimal experience. Follow these steps to login:\nSelect Network: Click on the dropdown list under the email input field, then select Custom. Enter Your Domain: In the modal that appears, type your domain (in this example, enterprise.starships.ws) and confirm by clicking the check mark button. Login with GitHub: With your domain now recognized, enter your email and click on Login with Github. This action will redirect you to GitHub, where you\u0026rsquo;ll need to authorize the web application to access your repositories. Rest assured, the token generated during this process is securely stored in your web browser only.\nCreate a Project Once logged in, you\u0026rsquo;ll land on the projects page. Here, (1) click on the \u0026ldquo;+\u0026rdquo; button to initiate a new project creation. In the modal that appears, you\u0026rsquo;re prompted to define your project: (1) Enter the project\u0026rsquo;s name, (2) provide a description, (3) decide whether the repositories related to this project should be private, and finally, (4) click on \u0026ldquo;Create project\u0026rdquo; to seal the deal. Successfully doing so will generate two repositories on GitHub for you—one for configuration and another for what we term as inline code.\nFollowing a successful creation, you\u0026rsquo;ll be navigated to the dashboard showcasing:\nProject Dashboard Node locations Commit history Git Branch For more details, (1) click on your avatar icon then (2) select Project Details. This modal provides essential details such as:\nYour GitHub token, handy for CLI usage Your project ID The repository holding configuration files The repository for inline function code Create a Serverless Function With the modal closed, navigate to the left side menu, (1) click on Functions, then (2) hit the \u0026ldquo;+\u0026rdquo; button to concoct a new function. To expedite the process, (1) press the \u0026ldquo;Template Select\u0026rdquo; button. In the subsequent modal, positioned centrally at the top, (1) pick a programming language—Rust, in this instance, (2) select a template—opting for ping pong, and (3) dismiss the modal. Compiling Rust takes time. For a swifter test, Go is recommended.\nBack in the function creation modal, nearly all fields should be prefilled except for the domain. (1) Click on Select Domain, then (2) choose GeneratedDomain, automatically provisioning a domain resource. Prior to proceeding, (1) review the code, which should process an HTTP request and return \u0026ldquo;pong\u0026rdquo;. Feel free to adjust the message, then (2) confirm the creation of the function by clicking the checkmark button. Your dashboard will now illustrate your newly minted function. Unlike conventional clouds, Taubyte leverages Git as the sole source of truth for resource creation. It\u0026rsquo;s time to commit your changes by clicking the green button located at the bottom right. The initial screen presents the diff in the configuration repository. (1) Examine the ping_pong.yaml for function configuration details, then (2) proceed to the next step. The following screen showcases code changes. By selecting lib.rs, you can inspect your code. Once reviewed, (2) move forward. Finally, (1) encapsulate your efforts in a commit message, then (2) click on Finish to complete the process. CI/CD After successfully pushing your changes, these are mirrored in your GitHub repositories. This step initiates CI/CD processes, crucial for deploying and testing your configurations and code. In the Taubyte console, (1) navigate to the Builds section to monitor the progress. Here, you\u0026rsquo;ll observe two pivotal jobs: (2) one for the configuration build and (3) another for compiling the code. Configuration builds conclude swiftly, whereas code compilation, especially for languages like Rust, will takes some time. For those with access to their nodes, a top command execution is enlightening. It allows you to witness firsthand which node is executing the build job, identifiable by the cargo process\u0026rsquo;s appearance at the forefront of system resource consumption. Test the Function With the build phase complete, it\u0026rsquo;s time to put your function to the test. From the Taubyte console\u0026rsquo;s left sidebar, (1) select Functions, then (2) click the thunderbolt icon adjacent to your newly created function. A new browser tab springs to life, presenting the function\u0026rsquo;s URL. Key observations include:\nThe URL features the generated domain and the /ping endpoint. The swift response from the function, echoing back the intended message. The impressively brief response time, clocking in at just 36ms. TLS Certificate The icing on the cake is the seamless handling of TLS certificates by the Taubyte cloud, automatically procured from Let\u0026rsquo;s Encrypt. This ensures your function endpoints are not only operational but secure. To appreciate this automated security enhancement, (1) click on the padlock icon located to the left of the URL, then (2) verify the connection\u0026rsquo;s security status. This streamlined approach to security underscores Taubyte\u0026rsquo;s commitment to providing a robust, developer-friendly platform, enabling you to focus on innovation rather than infrastructure.\nConclusion As we wrap up this journey through the creation and deployment of a serverless function on our very own cloud infrastructure, it\u0026rsquo;s clear that the barriers to competing with industry giants are not as insurmountable as they once seemed. By leveraging Taubyte\u0026rsquo;s platform, we\u0026rsquo;ve demonstrated that with the right tools and a bit of ingenuity, creating a cloud infrastructure capable of hosting scalable, secure, and efficient applications can be achieved with relative ease.\nThe process outlined in this article—from setting up our initial node to deploying a Rust-based serverless function—illustrates not just the potential for innovation, but the democratization of technology that platforms like Taubyte are fostering. The integration of CI/CD processes, automatic TLS certificate provisioning, and the utilization of Git for configuration and deployment underscore a shift towards more agile, developer-friendly cloud computing solutions.\nThis exploration is merely the beginning. The cloud you\u0026rsquo;ve built today lays the foundation for endless possibilities tomorrow. Whether you\u0026rsquo;re developing APIs, hosting dynamic web applications, or exploring the vast expanse of IoT, the infrastructure is now at your fingertips, ready to scale alongside your ambitions.\n","permalink":"/blog/posts/be-competitive-in-few-minutes/","summary":"Metal to Cloud: Outsmart Cloudflare, Netlify, and Vercel in Minutes","title":"Metal to Cloud: Outsmart Cloudflare, Netlify, and Vercel in Minutes"},{"content":"You\u0026rsquo;re reading this article, which means you either just discovered Taubyte or want to learn more about what it is and how it works. Well, let\u0026rsquo;s start with what it is, and then we will dive into how it works using an amazing tool we call dreamland.\nWhat is Taubyte? Taubyte simplifies the process of building a cloud computing platform, making it a no-brainer. Unlike other products, such as Kubernetes, which were not designed with software developers in mind nor as platforms, Taubyte eliminates the need for DevOps and platform engineering. In essence, Taubyte is designed for software developers, requiring no DevOps nor platform engineering skills. To achieve this, we aimed not just for automation but for autonomy.\nIf you\u0026rsquo;re a DevOps professional reading this, you might think it sounds too good to be true, or perhaps you\u0026rsquo;re inclined to deny its feasibility, fearing it will make your job obsolete. However, I invite you to stay with us because Taubyte is as real as it is open source. Moreover, I believe it will give DevOps and Platform Engineers an unprecedented advantage.\nLet\u0026rsquo;s get our hands dirty! The best way to learn something is by doing it, and that\u0026rsquo;s exactly what we\u0026rsquo;re going to do. All you need is npm. While there are other methods, we\u0026rsquo;ll stick to npm as it\u0026rsquo;s the simplest and most widely available, even on Windows.\nWhat we\u0026rsquo;ll do is install dreamland, a project hosted on github.com/taubyte/dreamland that allows you to run a Taubyte-based Cloud Computing Platform locally. It\u0026rsquo;s an excellent tool for local development and testing, but we\u0026rsquo;ll use it in a slightly different way.\nRun the following command to install dreamland:\n$ npm i @taubyte/dream Now, you should have the dream command-line tool available. Let\u0026rsquo;s start a cloud:\n$ dream new multiverse [INFO] Dreamland ready [SUCCESS] Universe blackhole started! You can ignore any ERROR messages you might see about seer.\nOnce you see SUCCESS, it means your cloud has been fully started.\nA first look First, let\u0026rsquo;s explore what\u0026rsquo;s happening using the command line. Run:\n$ dream status universe This should output something like:\n┌───────┬─────────────────────┬────────┬───────┐ │ Nodes │ elder@blackhole │ p2p │ 14051 │ │ ├─────────────────────┼────────┼───────┤ │ │ tns@blackhole │ http │ 14466 │ ... This lists all the running nodes. Each node could be running a specific protocol (e.g., tns or substrate) and will reflect that. Others will have a role like elder (bootstrap node) or client.\nAlso, @blackhole indicates that the node is part of the blackhole universe. Each universe represents a cloud and is cryptographically isolated from any other cloud on the peer-to-peer layer.\nOn the right side, you can see the TCP ports each node is using along with the number of copies.\nNow, let\u0026rsquo;s leave the terminal and head to console.taubyte.com where you\u0026rsquo;re going to locate the Dreamland button. Then click on it. The button will be disabled or hidden if dreamland is not detected.\nNow, locate the sidebar: (1) click on Network, then (2) on blackhole. After a few seconds, you should see something similar to: On the network graph, which you can manipulate, you can see all the same nodes as before from the CLI.\nIf you hover over any node, it\u0026rsquo;ll display the TCP ports it\u0026rsquo;s using. What\u0026rsquo;s with the mesh network? Hosts, or as we call them, Nodes, form a Taubyte-based Cloud Computing Platform and communicate with each other using a peer-to-peer network. Running locally through dreamland, all the nodes are interconnected, although this might not always be the case in production, especially if you have many nodes.\nThe peer-to-peer nature of Taubyte-based clouds gives them important characteristics like resilience and redundancy.\nProtocols While in production a node can run multiple protocols by defining a shape (a term reminiscent of the internal name tau had: odo, a reference to the shape-shifting Star Trek character), in dreamland, each node runs only one protocol. This design choice simplifies protocol debugging.\nWithout further ado, here\u0026rsquo;s what each protocol does:\nauth handles token validation and secret management. tns ensures project registry consistency across the cloud. seer is responsible for DNS resolution and load balancing. patrick bridges git events into CI/CD jobs. monkey executes CI/CD jobs. hoarder manages replication. substrate handles request processing and serving. gateway manages L7 load-balancing. The other nodes The other nodes, referred to as Simples (admittedly, not the best name), include elder and client. While they are not crucial for the purpose of this article and could be excluded when starting the universe, it\u0026rsquo;s helpful to understand their intended roles:\nelder nodes are used for bootstrapping. Since dreamland interconnects all nodes, an elder is included for testing purposes when using libdream. client nodes are lightweight and can be used to test protocols or peer-to-peer services deployed on the cloud. Note: Some fixtures, which will be covered in another article, may require Simples to function correctly.\nCreating a project Now, let\u0026rsquo;s create a project on this cloud. Although it can be done using tau-cli, which you might prefer if you\u0026rsquo;re a terminal enthusiast like me, we\u0026rsquo;re going to use the Web Console instead.\nOpen a new browser window or tab and navigate to console.taubyte.com.\n(1) Type your email, then (2) click on the network selection input, and finally (3) click on Dreamland/blackhole. Next, click the Login with GitHub button. You will be asked to grant the app GitHub access. This access is local to your browser and is used to create repositories related to your project, which will be cloned into a browser-based virtual file system.\nThe next screen will display \u0026ldquo;Your projects\u0026rdquo; and should show no projects. You\u0026rsquo;ll want to click on Create project. Enter a project name, a description, toggle private (unless you want the project repositories to be public), then click on Create Project. The Web Console will create two repositories: one for configuration, containing mainly YAML files, and another for inline code, containing code in different languages to be compiled to WebAssembly. If everything goes well, you\u0026rsquo;ll be directed to the dashboard. Creating a Function Taubyte-based Clouds support serverless functions. Let\u0026rsquo;s create one!\nClick on Functions in the side menu, then on the + button. To expedite the process, we\u0026rsquo;ll use a template. Skip filling any field for now and click on the Template Select button. This action opens another modal at the top where you can select a template. Although you can choose Go, Rust, or AssemblyScript at the time of writing this article, we\u0026rsquo;ll keep it simple and go for Go! (pun intended). So: (1) select Go, (2) select ping_pong, and finally (3) close the modal. All fields have been automatically filled except for the domains. Proceed by (1) clicking on the list and (2) selecting GeneratedDomain. This action will create a domain resource for you. It\u0026rsquo;s worth noting that the Web Console clones your repositories in-browser, meaning there\u0026rsquo;s always a code equivalent to everything you do. Let\u0026rsquo;s review the YAML config by clicking on the Yaml tab. You will see YAML code resembling the following:\nid: \u0026#34;\u0026#34; description: Returns pong to a ping over HTTP tags: [] source: . trigger: type: https method: GET paths: - /ping domains: - GeneratedDomain execution: timeout: 10s memory: 10MB call: ping Most of this YAML should be self-explanatory, but let me clarify a few points:\nsource: can either be . for inline code or the name of a library (to be explored in other articles). execution.call: specifies the function to be executed and must be exported by the WebAssembly module. Next, let\u0026rsquo;s inspect the code. The Web Console features a modest code editor useful for quick inline code updates. Access it by clicking on the Code tab. In the editor, you will observe (1) the usual Go files including go.mod, (2) the code for our handler function ping, and (3) a .taubyte folder defining how the function is built. While understanding the entire code or mastering Go isn\u0026rsquo;t necessary, I\u0026rsquo;ll explain a few basic concepts that will map in a way or another to any serverless function in supported languages:\nThe package name can be anything except main. The building container, taubyte/go-wasi on Docker Hub, wraps your function in a special main function. The github.com/taubyte/go-sdk package simplifies interactions with the Taubyte VM, making it straightforward to use VM primitives. We use tinygo to compile Go into small, efficient WebAssembly modules. To export a function, annotate it with the //export comment. Taubyte supports various trigger types, so handlers receive an event. We care about efficiency, so event.Event is really a wrapper of a uint32, minimizing unnecessary memory allocation and copying. Click Done to proceed. The function should now appear listed. Everything done so far is confined to the virtual filesystem in your browser. To apply these changes, we need to push them. Find the green button at the bottom right of the screen and click on it. A modal will guide you through the code changes, starting with configuration changes. Click on the domains folder, then open the GeneratedDomain.yaml file. Copy the FQDN generated for you as we will need it later:\nfqdn: gftxhd6h0.blackhole.localtau Click on Next to review code changes. One more click on Next takes you to the final step, where you\u0026rsquo;ll (1) enter a commit message and (2) push the changes to GitHub. In production, this push would trigger an event captured by patrick. However, because we\u0026rsquo;re using dreamland and GitHub cannot reach your nodes directly, we run a fixture called push-all to emulate the git events. Switch back to your terminal and run:\n$ dream inject push-all Return to the Web Console and, on the side menu, click on Builds. You should see two CI/CD jobs, one for configuration and one for code. After a few seconds, the build should complete. Click on Refresh if it seems delayed. Then, click on the stack icon to view the ping_pong function. Executing the Function Now that our function has been built and its configuration published on tns, we can execute it by hitting the endpoint. Since we\u0026rsquo;re running a local cloud, we need to find out which port the substrate (or gateway, if you\u0026rsquo;re using one) node uses to handle HTTP requests. To do this, run:\n$ dream status substrate In my case, the HTTP port is 14529.\n┌─────────────────────┬────────┬───────┐ │ substrate@blackhole │ copies │ 1 │ │ ├────────┼───────┤ │ │ dns │ 14304 │ │ ├────────┼───────┤ │ │ http │ 14529 │ │ ├────────┼───────┤ │ │ p2p │ 14282 │ └─────────────────────┴────────┴───────┘ You can test the function using curl as follows, making sure to replace gftxhd6h0.blackhole.localtau with your own generated domain:\n$ curl -H \u0026#34;Host: gftxhd6h0.blackhole.localtau\u0026#34; http://127.0.0.1:14529/ping Output:\nPONG Alternatively, you can add the generated domain to your local hosts file (/etc/hosts in my case) as follows:\n$ sudo vi /etc/hosts 127.0.0.1 gftxhd6h0.blackhole.localtau Save and exit, then run curl again but without the Host header:\n$ curl http://gftxhd6h0.blackhole.localtau:14529/ping Output:\nPONG If you\u0026rsquo;ve added the generated domain to your /etc/hosts, you can also use the Web Console to hit the function\u0026rsquo;s endpoint: (1) In the sidebar, click on Functions, then (2) click on the thunder icon. This action opens a new tab where you should see something like this: Congratulations! You\u0026rsquo;ve successfully created a cloud and executed a serverless function on it!\nWhat Just Happened! In this section, we\u0026rsquo;ll take a step back to review the processes and protocols involved in each step of deploying and executing a serverless function with Taubyte. This overview will help clarify the interactions between different components and the significance of each protocol in the overall architecture.\nProject Creation The creation of a project is predominantly a client-side operation, facilitated by either the Web Console or the tau-cli. This process involves direct communication with GitHub to establish the necessary repositories. Only towards the end does the auth protocol come into play, tasked with registering these repositories. This registration process includes storing critical secrets such as the deployment key, essential for cloning code during CI/CD processes, and the webhook secret, used to authenticate events coming from GitHub.\nThe sequence diagram below illustrates these interactions in detail:\nsequenceDiagram participant Client as Web Console/tau-cli participant GitHub participant Auth as auth Note over Client,GitHub: Project creation initiated on client side Client-\u0026gt;\u0026gt;GitHub: Create repositories Note over GitHub: Repositories and necessary metadata created GitHub--\u0026gt;\u0026gt;Client: Confirm repository creation Note over Client,Auth: Only at the end does auth play a role Client-\u0026gt;\u0026gt;Auth: Register repositories Note over Client,Auth: Includes storing deployment key and webhook secret Auth--\u0026gt;\u0026gt;Client: Confirm registration and storage of secrets Pushing Changes to GitHub When changes are pushed to GitHub, a sequence of events is triggered, initiating a process that involves multiple protocols to manage and execute CI/CD jobs. The patrick protocol plays a pivotal role in verifying the legitimacy of events and creating jobs, while the monkey protocol is responsible for the execution of these jobs. Subsequently, the tns stores and replicates the compiled configuration, and the hoarder protocol ensures the replication of updated assets.\nThe sequence diagram below visualizes this workflow:\nsequenceDiagram participant GitHub as GitHub participant Patrick as Patrick participant Monkey as Monkey participant TNS as TNS Protocol participant Hoarder as Hoarder Note over GitHub,Patrick: git push GitHub-\u0026gt;\u0026gt;Patrick: Github Web Hook Patrick-\u0026gt;\u0026gt;Patrick: Verify events are legit Patrick-\u0026gt;\u0026gt;Patrick: Create jobs for events Patrick--\u0026gt;\u0026gt;Monkey: Broadcast jobs Note over Monkey: Bid for the job(s) Monkey-\u0026gt;\u0026gt;Monkey: Job Execution Note over TNS: Assuming successful job execution Monkey-\u0026gt;\u0026gt;TNS: Publish configuration Monkey-\u0026gt;\u0026gt;Monkey: File chunked, structured in DAG Monkey-\u0026gt;\u0026gt;TNS: Update Asset CIDs Monkey--\u0026gt;\u0026gt;Hoarder: Notify of new CID Hoarder-\u0026gt;\u0026gt;Hoarder: Replicate Note over Monkey,Hoarder: Replicated by at least one node It\u0026rsquo;s important to note that because we are using Dreamland, a simulated environment, there\u0026rsquo;s no direct way for GitHub to communicate with your nodes. This limitation is addressed by using the fixture called push-all, which emulates the git events that would typically trigger the CI/CD process in a production environment.\nHitting the Endpoint The process for handling a request at an endpoint varies depending on the network\u0026rsquo;s configuration. In a simple setup without gateways and HTTPS, the request\u0026rsquo;s host name is resolved by the seer protocol before the request itself is processed by a substrate node. However, in networks with gateways or HTTPS requests, additional steps, like retreiving x509 certificate from auth, are involved.\nThe diagrams below detail these processes for different configurations:\nWithout Gateway and HTTPS: sequenceDiagram participant Client participant Seer as Seer participant Substrate participant TNS as TNS participant Peers as Other Peers Client-\u0026gt;\u0026gt;Seer: Resolve Host Seer--\u0026gt;\u0026gt;Client: Nearest Substrate IP Client-\u0026gt;\u0026gt;Substrate: HTTP request Substrate-\u0026gt;\u0026gt;TNS: Lookup function TNS--\u0026gt;\u0026gt;Substrate: Returns config Substrate-\u0026gt;\u0026gt;Peers: Request WebAssembly module Peers--\u0026gt;\u0026gt;Substrate: Download WebAssembly module Substrate-\u0026gt;\u0026gt;Substrate: Execute handler Substrate--\u0026gt;\u0026gt;Client: Relay response With Gateway: sequenceDiagram participant Client participant Seer as Seer DNS participant Gateway participant Substrate Client-\u0026gt;\u0026gt;Seer: DNS query for endpoint Seer--\u0026gt;\u0026gt;Client: Resolve to nearest Gateway IP Client-\u0026gt;\u0026gt;Gateway: HTTP request Gateway-\u0026gt;\u0026gt;Substrate: Establish p2p connection to Substrates Gateway-\u0026gt;\u0026gt;Substrate: Tunnel HTTP to best Substrate Note over Gateway,Substrate: Handling by Substrate is similar to before With HTTPS: sequenceDiagram participant Client participant Gateway_Substrate as Gateway/Substrate participant Auth as Auth Protocol Client-\u0026gt;\u0026gt;Gateway_Substrate: HTTPS request Gateway_Substrate-\u0026gt;\u0026gt;Auth: Request certificate Auth--\u0026gt;\u0026gt;Gateway_Substrate: Return certificate Gateway_Substrate--\u0026gt;\u0026gt;Client: Return certificate to Client Note over Gateway_Substrate,Client: Secure connection established Note: Taubyte supports the Automatic Certificate Management Environment (ACME) protocol for auto-generating certificates using Let’s Encrypt.\nThese diagrams demonstrate the seamless and autonomous nature of the Taubyte platform, which requires no manual configuration and ensures a smooth deployment and execution process for serverless functions.\nConclusion This guide has introduced you to Taubyte, illustrating its approach to simplifying cloud computing for developers. By walking you through the creation of a cloud environment and deploying a serverless function, we\u0026rsquo;ve showcased Taubyte\u0026rsquo;s exceptional developer experience and practicality. Our hands-on approach aimed to highlight the ease with which developers can leverage Taubyte to create and manage cloud environments without the complexities traditionally associated with cloud computing.\nTaubyte is designed to empower developers, enabling you to focus on innovation rather than infrastructure. Whether you\u0026rsquo;re taking your first steps into cloud computing or looking to optimize your development workflow, Taubyte provides a streamlined, developer-centric platform that simplifies cloud creation and management.\nAs you continue to explore Taubyte, remember that this introduction is just the starting point. Taubyte\u0026rsquo;s open-source nature invites you to dive deeper, experiment, and contribute to its evolving ecosystem. Welcome to a new era of cloud computing with Taubyte, where creating clouds is as intuitive as developing software.\n","permalink":"/blog/posts/introduction-to-taubyte/","summary":"Introduction to Taubyte","title":"Introduction to Taubyte"},{"content":"In this article, I\u0026rsquo;ll go over how to use the LLM (or GPT) capabilities of taubyte-llama-satellite. I\u0026rsquo;m assuming that you already know how to create a project and a function on a Taubyte-based Cloud Computing Network. If not, please refer to Taubyte\u0026rsquo;s Documentation.\nLLAMA Satellite A Taubyte Cloud can provide LLM capabilities through what we call a Satellite. In this case it\u0026rsquo;s taubyte-llama-satellite which exports llama.cpp capabilities to the Taubyte Virtual Machine, thus giving Serverless Functions (or DFunctions, as per Taubyte\u0026rsquo;s terminology) LLM features.\nLLAMA SDK Satellites export low-level functions that aren\u0026rsquo;t very intuitive to use directly. Fortunately, it\u0026rsquo;s possible to address that with a user-friendly SDK. The Go SDK for taubyte-llama-satellite can be found here.\nGet Ready Before proceeding, let\u0026rsquo;s ensure you have a project and a DFunction ready to go. If not, please refer to \u0026ldquo;Create a Function\u0026rdquo;.\nLet\u0026rsquo;s Code! A good practice is to clone your code locally using git or the tau command-line. Make sure you have Go installed, then run:\ngo get github.com/samyfodil/taubyte-llama-satellite Our Basic Function If you followed the steps from Taubyte\u0026rsquo;s Documentation, your basic function should look something like this:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; ) //export ping func ping(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } h.Write([]byte(\u0026#34;PONG\u0026#34;)) return 0 } Let\u0026rsquo;s modify it so it uses the POST body as the prompt. Note: I\u0026rsquo;ve changed the function\u0026rsquo;s name to predict. Ensure this change is reflected in your configuration by setting the entry point to predict and modifying the method from GET to POST.\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } return 0 } Predict The LLAMA SDK exports two main methods, Predict and Next. Let\u0026rsquo;s start by creating a prediction:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;github.com/samyfodil/taubyte-llama-satellite/sdk\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } p, err := sdk.Predict( string(prompt), ) if err != nil { panic(err) } return 0 } This code will submit a request for a prediction to the satellite, which will put it in a queue because predictions are resource-intensive (especially on the GPU), and return a prediction.\nJust like when interacting with any LLM, you can customize the request like so:\np, err := sdk.Predict( string(prompt), sdk.WithTopK(90), sdk.WithTopP(0.86), sdk.WithBatch(512), ) You can find all possible options here.\nGet Tokens After submitting a prediction to the satellite, you need to collect tokens. You can do so by calling p.Next(), which will block until a new token is available or the prediction is completed or canceled. Note that you can use NextWithTimeout if you\u0026rsquo;d like to set a deadline.\nNow, let\u0026rsquo;s wrap up our function:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;github.com/samyfodil/taubyte-llama-satellite/sdk\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } p, err := sdk.Predict( string(prompt), sdk.WithTopK(90), sdk.WithTopP(0.86), sdk.WithBatch(512), ) if err != nil { panic(err) } for { token, err := p.Next() if err == io.EOF { break } else if err != nil { panic(err) } h.Write([]byte(token)) h.Flush() //flush } return 0 } The call to h.Flush() will send the token to the client (browser) immediately. If you\u0026rsquo;d like to recreate the AI typing experience provided by ChatGPT, you can use something like:\nawait axios({ method: \u0026#34;post\u0026#34;, data: prompt, url: \u0026#34;\u0026lt;URL\u0026gt;\u0026#34;, onDownloadProgress: (progressEvent) =\u0026gt; { const chunk = progressEvent.currentTarget.responseText; gotToken(chunk); }, }) Conclusion In this guide, we\u0026rsquo;ve walked through how to leverage the LLM (or GPT) capabilities provided by 8ws on a Taubyte-based Cloud Computing Network. We\u0026rsquo;ve explored the concept of a LLAMA Satellite and its role in exporting LLM capabilities to the Taubyte Virtual Machine. Furthermore, we\u0026rsquo;ve discussed the importance and functionality of the LLAMA SDK, which makes interacting with the Satellite\u0026rsquo;s low-level functions more intuitive.\nWe\u0026rsquo;ve gone through a practical example of how to use these tools in a Taubyte project, specifically demonstrating how to fetch tokens and use the Predict method. We\u0026rsquo;ve also shown how you can fine-tune your requests to the SDK and manage the tokens returned by the Satellite. By the end of the guide, you should be equipped to create a serverless function on Taubyte that can generate predictions from user-provided prompts, similar to how AI like ChatGPT works.\nHarnessing the power of Taubyte and the LLAMA Satellite, you\u0026rsquo;re now ready to incorporate large language model capabilities into your projects, bringing a new level of interactivity and AI-driven responses to your applications.\n","permalink":"/blog/posts/add-llm-to-your-project/","summary":"Using LLAMA in WebAssembly","title":"Using LLAMA in WebAssembly"},{"content":"In this article, I\u0026rsquo;ll go over how to use the LLM (or GPT) capabilities of taubyte-llama-satellite. I\u0026rsquo;m assuming that you already know how to create a project and a function on a Taubyte-based Cloud Computing Network. If not, please refer to Taubyte\u0026rsquo;s Documentation.\nLLAMA Satellite A Taubyte Cloud can provide LLM capabilities through what we call a Satellite. In this case it\u0026rsquo;s taubyte-llama-satellite which exports llama.cpp capabilities to the Taubyte Virtual Machine, thus giving Serverless Functions (or DFunctions, as per Taubyte\u0026rsquo;s terminology) LLM features.\nLLAMA SDK Satellites export low-level functions that aren\u0026rsquo;t very intuitive to use directly. Fortunately, it\u0026rsquo;s possible to address that with a user-friendly SDK. The Go SDK for taubyte-llama-satellite can be found here.\nGet Ready Before proceeding, let\u0026rsquo;s ensure you have a project and a DFunction ready to go. If not, please refer to \u0026ldquo;Create a Function\u0026rdquo;.\nLet\u0026rsquo;s Code! A good practice is to clone your code locally using git or the tau command-line. Make sure you have Go installed, then run:\ngo get github.com/samyfodil/taubyte-llama-satellite Our Basic Function If you followed the steps from Taubyte\u0026rsquo;s Documentation, your basic function should look something like this:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; ) //export ping func ping(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } h.Write([]byte(\u0026#34;PONG\u0026#34;)) return 0 } Let\u0026rsquo;s modify it so it uses the POST body as the prompt. Note: I\u0026rsquo;ve changed the function\u0026rsquo;s name to predict. Ensure this change is reflected in your configuration by setting the entry point to predict and modifying the method from GET to POST.\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } return 0 } Predict The LLAMA SDK exports two main methods, Predict and Next. Let\u0026rsquo;s start by creating a prediction:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;github.com/samyfodil/taubyte-llama-satellite/sdk\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } p, err := sdk.Predict( string(prompt), ) if err != nil { panic(err) } return 0 } This code will submit a request for a prediction to the satellite, which will put it in a queue because predictions are resource-intensive (especially on the GPU), and return a prediction.\nJust like when interacting with any LLM, you can customize the request like so:\np, err := sdk.Predict( string(prompt), sdk.WithTopK(90), sdk.WithTopP(0.86), sdk.WithBatch(512), ) You can find all possible options here.\nGet Tokens After submitting a prediction to the satellite, you need to collect tokens. You can do so by calling p.Next(), which will block until a new token is available or the prediction is completed or canceled. Note that you can use NextWithTimeout if you\u0026rsquo;d like to set a deadline.\nNow, let\u0026rsquo;s wrap up our function:\npackage lib import ( \u0026#34;github.com/taubyte/go-sdk/event\u0026#34; \u0026#34;github.com/samyfodil/taubyte-llama-satellite/sdk\u0026#34; \u0026#34;io\u0026#34; ) //export predict func predict(e event.Event) uint32 { h, err := e.HTTP() if err != nil { return 1 } defer h.Body().Close() prompt, err := io.ReadAll(h.Body()) if err != nil { panic(err) } p, err := sdk.Predict( string(prompt), sdk.WithTopK(90), sdk.WithTopP(0.86), sdk.WithBatch(512), ) if err != nil { panic(err) } for { token, err := p.Next() if err == io.EOF { break } else if err != nil { panic(err) } h.Write([]byte(token)) h.Flush() //flush } return 0 } The call to h.Flush() will send the token to the client (browser) immediately. If you\u0026rsquo;d like to recreate the AI typing experience provided by ChatGPT, you can use something like:\nawait axios({ method: \u0026#34;post\u0026#34;, data: prompt, url: \u0026#34;\u0026lt;URL\u0026gt;\u0026#34;, onDownloadProgress: (progressEvent) =\u0026gt; { const chunk = progressEvent.currentTarget.responseText; gotToken(chunk); }, }) Conclusion In this guide, we\u0026rsquo;ve walked through how to leverage the LLM (or GPT) capabilities provided by 8ws on a Taubyte-based Cloud Computing Network. We\u0026rsquo;ve explored the concept of a LLAMA Satellite and its role in exporting LLM capabilities to the Taubyte Virtual Machine. Furthermore, we\u0026rsquo;ve discussed the importance and functionality of the LLAMA SDK, which makes interacting with the Satellite\u0026rsquo;s low-level functions more intuitive.\nWe\u0026rsquo;ve gone through a practical example of how to use these tools in a Taubyte project, specifically demonstrating how to fetch tokens and use the Predict method. We\u0026rsquo;ve also shown how you can fine-tune your requests to the SDK and manage the tokens returned by the Satellite. By the end of the guide, you should be equipped to create a serverless function on Taubyte that can generate predictions from user-provided prompts, similar to how AI like ChatGPT works.\nHarnessing the power of Taubyte and the LLAMA Satellite, you\u0026rsquo;re now ready to incorporate large language model capabilities into your projects, bringing a new level of interactivity and AI-driven responses to your applications.\n","permalink":"/blog/posts/add-llm-to-your-cloud/","summary":"Add LLAMA Capability to Your Cloud","title":"Add LLAMA Capability to Your Cloud"}]