DEV Community: Daniel Adeboye

How much compute does an AI coding agent need?

Daniel Adeboye — Wed, 28 Oct 2026 08:52:58 +0000

Moving a coding agent like Claude Code or Codex from your laptop to a cloud environment raises a practical question: how much compute does it actually need?

Give it too little, and dependency installs, builds, or tests can run out of memory or take too long. Give it too much, and you end up paying for resources the agent barely uses while waiting for the model to respond.

When using a remotely hosted model, the model itself runs on the provider's servers. The coding agent runs in your environment, where it reads your code, installs dependencies, runs commands, and executes tests. These tasks have different compute requirements, so the right configuration depends on what you're building and how you run your agents.

Where does an AI coding agent use compute?

A coding agent runs a loop. It sends the task and context to a model, receives an action, runs that action in the environment, and sends the result back. The two halves of that loop have very different compute needs.

The agent loop is light: The agent CLI manages the conversation, reads and edits files, searches the codebase, and waits for model responses. Much of its time may be spent waiting on the network. When using a remotely hosted model, the model itself doesn't run in your environment.

The work the agent runs is heavy: Every time the agent runs a command, that command uses your environment's resources:

Dependency installs: npm install, pip install, or cargo fetch use CPU, memory, network, and disk.
Builds and compilation: Compilers, bundlers, and linkers can be CPU-intensive and use several GB of memory.
Test suites: Test runners may run multiple workers in parallel, while integration tests can start databases or browsers.
Language tooling: Type checkers, linters, and language servers can hold significant parts of the codebase in memory.
Development servers and services: A web server, database, or queue started for testing continues consuming resources while it runs.

An agent working on a small Python script needs very little compute. The same agent working on a large TypeScript monorepo and running the full test suite after each change needs a lot more. The agent is the same in both cases. The workload is not.

What are the minimum requirements to run a coding agent?

The agent vendors publish minimum requirements for the CLI itself.

Agent	Published minimum	Source
Claude Code	4 GB+ RAM, x64 or ARM64 processor, supported operating systems	Claude Code setup docs
Codex CLI	4 GB RAM minimum, 8 GB recommended; macOS 12+, Ubuntu 20.04+/Debian 10+, or Windows 11 via WSL2	Codex install docs

Treat these as the floor for running the agent, not as a recommended size for real development work. An environment that meets the minimum may run the CLI but struggle once the agent installs dependencies, builds an application, or runs memory-intensive tests. Neither vendor specifies a universal CPU minimum for these workloads because the compute required depends heavily on what the agent runs.

How much CPU, memory, and disk does a coding agent need by workload?

No vendor publishes universal sizing recommendations by project type, so the table below provides starting points based on typical development workloads. These are estimates, not benchmarked minimums. Use them to choose an initial configuration, then measure a real task and adjust.

Workload	Starting vCPU	Starting memory	Starting disk	Likely bottleneck
Scripts, small repositories, documentation	1 to 2	2 to 4 GB	10 GB	Memory when installing large dependencies
Typical Node.js or Python web apps with unit tests	2 to 4	4 to 8 GB	20 GB	Memory during installs and tests; disk from dependencies and caches
Compiled languages such as Go, Rust, Java, or Kotlin	4 to 8	8 to 16 GB	20 to 50 GB	CPU during compilation; memory for linkers and build tools
Monorepos and large test suites	4 to 8+	16 to 32 GB	50 to 100 GB	Memory from parallel test workers and type checking; disk from build caches
Agents running databases and services alongside the code	Add resources based on measured service usage	Add resources based on measured service usage	Allow for database files and other persistent data	Memory and CPU contention between services and development tasks

Two rules of thumb apply across most workloads. First, monitor memory closely because running out can cause processes to be killed or tasks to fail. Second, account for disk growth over time as dependency caches, build artifacts, and container images accumulate.

CPU matters just as much when workloads are compute-intensive. If compilation or tests are CPU-bound, additional memory alone won't make them finish faster. Measure the bottleneck before scaling.

Which resource runs out first?

Resource	Symptoms	Common causes	Fix
Memory	A process exits with code 137, reports `Killed`, or produces an out-of-memory error during an install or test run	Parallel test workers, type checkers on large codebases, JVM heap usage, or several services running at once	Add memory or reduce parallelism with options such as Jest's `--maxWorkers` or Gradle's `--max-workers`
CPU	Builds and tests run slowly, extending the time each agent task takes	Compilation, bundling, and large test suites	Add vCPUs for build-heavy projects and configure build parallelism to match the available resources
Disk	`No space left on device` during installs, builds, or Git operations	`node_modules`, package caches, build artifacts, container images, or large Git histories	Increase disk capacity, clear unnecessary caches, or use shallow clones where appropriate
Network	Dependency installs and image pulls are slow or time out	Large dependency trees, registry issues, or downloads from distant registries	Use a region closer to your registries, or configure a package cache or mirror

Memory failures can be particularly disruptive for unattended agents. A developer may notice an out-of-memory error immediately, but an agent might retry the same failing command or stop making progress before anyone notices. Monitoring resource usage and capturing failed commands helps identify these problems sooner.

Build tools can also detect the host's CPU count rather than the resources available to the environment. This can lead to more parallel workers than the environment can handle efficiently. If a build is slow despite having enough vCPUs, check the worker count and set it explicitly.

How does running agents in parallel change compute needs?

Running several agents at once changes the total compute you need, and how you allocate it depends on where they run.

Several agents in one environment: Share its CPU, memory, and disk, so their resource usage can add up quickly. If two agents each run memory-intensive tests at the same time, their combined peak memory usage, plus the agent processes and other services, may exceed the available RAM. They also share ports and caches, which can save disk space but cause conflicts if two agents start the same development server.
One environment per agent: Gives each agent its own resources, sized for its task. The total resource allocation is the sum of all environments, but one agent running out of memory is less likely to affect the others, and a lightweight task doesn't need the same configuration as a heavy one.

For a few small, related tasks, sharing a larger environment can work well. For long-running or resource-intensive tasks, separate environments make it easier to allocate resources independently and prevent agents from competing with each other.

If you're looking to run multiple agents in parallel, see this guide on how to run multiple coding agents in parallel.

Does an AI coding agent need a GPU?

No, in most cases. Coding agents such as Claude Code and Codex use remotely hosted models, so the environment generally needs CPU and memory for the agent and the work it runs.

A GPU is useful in two situations. The first is when you host your own model, for example, an open-weight coding model served with vLLM. The GPU runs the model, usually in a separate environment from the agent. The second is when the code the agent works on needs a GPU, such as machine learning training or inference code with tests that run on CUDA.

How do you choose the right compute configuration?

Start with the workload, not the agent: Pick a starting size from the workload table above, based on the project's language, build process, and test suite.
Measure a real task: Run the agent on a representative task and monitor resource usage while it works.
Size for peak usage, not the average: An agent may spend much of its time waiting for model responses, keeping average CPU usage low. Builds, dependency installs, and test runs can create short-lived resource spikes. If peak memory approaches the environment's limit, add memory or reduce parallelism before running the agent unattended.
Size per task, not per developer: A documentation fix and a full refactor with a test suite have different resource requirements. If your platform lets you choose resources for each environment, use smaller configurations for lightweight tasks and larger ones for demanding workloads.
Pause or delete idle environments: Resources that remain allocated while an environment is idle can add unnecessary costs. Where supported, pause environments when tasks finish and resume them when needed. This lets you allocate enough compute for demanding tasks without paying for idle compute indefinitely.

How do you size coding agent environments on Northflank?

The compute requirements above are starting points, not fixed rules. The best configuration depends on your repository, build process, test suite, and the number of agents running at once. Northflank Cloud Harnesses let you apply this workload-based approach in the cloud, with configurable compute, persistent workspaces, and resource usage metrics.

Each Harness runs in its own Kata microVM and supports tools such as Claude Code, Codex, OpenCode, Pi, Cursor, or your own agent.

You can start with Northflank's free Sandbox tier, where a Harness can use up to 1 vCPU and 1 GB of RAM. This is a starting point for lightweight coding tasks and trying out cloud-based agents. For larger repositories, dependency-heavy projects, or demanding test suites, you can move to a larger compute plan.

For example, you could start with these managed-cloud plans:

Example workload	Plan	vCPU	Memory	Cost per hour
Lightweight tasks and experimentation	Free Sandbox	Up to 1	Up to 1 GB	Free
Small scripts or documentation tasks	nf-compute-100-2	1	2 GB	$0.03333
Typical application development	nf-compute-200	2	4 GB	$0.06667
Larger builds and test suites	nf-compute-400	4	8 GB	$0.1333
More demanding development workloads	nf-compute-800-16	8	16 GB	$0.2667

These are illustrative starting configurations, not guaranteed requirements. Monitor CPU and memory usage during a representative task and resize when you identify a bottleneck. You can find additional plans and current rates on the Northflank pricing page.

Compute is billed by the second. When an agent finishes its work, you can pause its Harness to stop compute billing while preserving its workspace, then resume it when you need it again. Each Harness has a persistent home directory configurable from 5 GB to 100 GB, with the option to expand storage as the project grows.

For teams that need more control over their infrastructure, Northflank also supports bring-your-own-cloud (BYOC) deployments on AWS, Google Cloud, Azure, Oracle, and CoreWeave.

The advantage is that you don't have to choose one oversized environment for every coding task. You can start with the resources a workload needs, measure actual usage, and adjust the configuration as your projects grow.

Conclusion

An AI coding agent needs relatively little compute for the agent process itself. The vendors' minimum requirements cover running the agent, but the right size depends on the work it runs: dependency installs, builds, test suites, and services. Start with a configuration that fits the workload, measure peak resource usage during a real task, and scale the resource that's actually limiting performance.

If you run agents in the cloud, a platform that bills by the second and lets you pause environments can help control costs while giving agents the resources they need. Northflank Cloud Harnesses offer a free Sandbox tier for getting started, with larger compute plans available when your workload needs more resources.

How to Build a Python API from Scratch with FastAPI

Daniel Adeboye — Thu, 05 Sep 2024 07:10:07 +0000

Python has always been my go-to when building APIs for any of my projects, and in this tutorial, we’re going to build a simple blog application API using FastAPI. We’ll start with structuring our FastAPI project, installing the necessary dependencies, creating our application model structure, writing the functionalities for our application, and finally testing out our API.

💡 If you are interested in building something similar using Python Flask, you can check out my 1-hour-long video tutorial on Youtube.

Prerequisites

To follow this tutorial, you should have:

Basic knowledge of Python
Basic knowledge of API and how it works.

These are the steps that we will cover:

Step 1 - Project Setup
Step 2 - Running our first basic application
Step 3 - Creating our Application Model Structure
Step 4 - Writing our Application CRUD functionalities
Step 5 - Testing our API endpoints
Step 6 - Exercise

Step 1 - Project Setup

In this section we will focus on setting up our project, starting with folder creation, environment setup, and installing necessary dependencies.

Folder Creation

On your terminal create a project directory with any name of your choice. In my case I will call my project “anvil-blog”. You can also do this using your computer’s file explorer user interface.

$ mkdir anvil-blog

After creating your application folder, you will need to change your directory into “anvil-blog”.

$ cd anvil-blog

Environment Setup

Inside your project directory, we will create and activate a virtual environment, which will house all of our application dependencies. In this case, I called it “env”.

$ python -m venv env
$ env/bin/activate

Installing Dependencies

To build our API using FastAPI, we need to install necessary dependencies that will help our application run smoothly, and below are what we need:

FastAPI - A web framework for building APIs with Python.
Uvicorn - An ASGI web server implementation for Python
Pydantic - A data validation library for Python.

Run the command below to install these packages:


(env)$ pip install fastapi uvicorn pydantic

Step 2 - Running our first basic application

Application Setup

Now that we have our project environment setup, it’s time to write some FastAPI code. Create a new file in your project folder and name it “main.py”, this is where we’ll write all of our application code.

Let’s add this code to our “main.py” file.

import uvicorn
from fastapi import FastAPI

app = FastAPI()

@app.get("/")
def anvil():
    return {"hello": "world"}

if __name__ == "__main__":

    uvicorn.run(app, host="0.0.0.0", port=8000)

Let’s break down the above code:

@app.get("/") defines a route for our FastAPI application. When someone accesses the root URL (/), the anvil function is called. This function simply returns a JSON response with the message "hello": "world".
if __name__ == "__main__": ensures that our code runs only when the script is executed directly. Inside this block, uvicorn.run is called to start the Uvicorn server, which serves our FastAPI app at the specified host (0.0.0.0) and port (8000).

Running our Application Server

To run our application server run the command below in your terminal:

(env)$ python main.py

You should get similar result as the image below:

You can now access your application at http://localhost:8000/.

🎉 Congratulations, we have successfully run our first FastAPI application.

Step 3 - Creating our Application Model Structure ****

Earlier we installed Pydantic, a library that helps us validate and serialize data schemas, we’ll use this library to create our application model structure.

Let’s add this code to our “main.py” file:

from pydantic import BaseModel
from typing import List, Optional
from uuid import UUID, uuid4

class Blog(BaseModel):
    id: Optional[UUID] = None
    title: str
    description: str

Now, let's break down the code:

We've used UUID also known as universally unique identifier, to ensure that each Blog instance has a unique identifier. This helps us guarantee that the id for each blog post is always unique.
The Optional type indicates that the id field is not required when a new blog post is created. If the id is not provided, it defaults to None, allowing the system to generate it automatically.

Creating a Temporary Database for our Model

Because we are not using a real database in this tutorial, we are going to use a list instead. Let’s add the code below under our Blog model:

blogs = []

Here is what your “main.py” file should look like:

import uvicorn
from fastapi import FastAPI
from pydantic import BaseModel
from typing import List, Optional
from uuid import UUID, uuid4

app = FastAPI()

class Blog(BaseModel):
    id: Optional[UUID] = None
    title: str
    description: str

blogs = []

if __name__ == "__main__":

    uvicorn.run(app, host="0.0.0.0", port=8000)

Step - 4 Writing our Application CRUD functionalities

You might be curious about what CRUD stands for. It represents the four main operations commonly performed in most applications: Create, Read, Update, and Delete.

Create Blog Post API

In the Create Blog Post API, we're going to allow users to create blog posts. Here's how it works:

@app.post("/blogs/", response_model=Blog)
def create_blog(blog: Blog):
    blog.id = uuid4()
    blogs.append(blog)
    return blog

Now, let's break down the code:

response_model=Blog tells FastAPI to use the Blog model to structure the JSON response returned from the /blogs/ route.
(blog: Blog) specifies that we want to accept a new blog post using our Blog model.
blogs.append(blog) as you might already know adds the new blog post to our temporary database, which is represented by the blogs[].

Get Blog List API

In the Get Blog List API, we're going to allow users to retrieve all the blog posts they have created. Here's how it works:

@app.get("/blogs/", response_model=list[Blog])
def list_blogs():
    return blogs

Now, let's break down the code:

response_model=list[Blog] as you might already know tells FastAPI that the response will be a list of Blog objects.
return blogs: This line returns the entire list of blog posts stored in our temporary database, which is the blogs[].

Update Blog Post API

In the Update Blog Post API, we allow users to modify an existing blog post by providing its unique identifier (UUID) and the new data they wish to update. Here’s how it works:

@app.put("/blog/{blog_id}", response_model=Blog)
def update_blog(blog_id: UUID, blog_update: Blog):
    for idx, blog in enumerate(blogs):
        if blog.id == blog_id:
            updated_blog = blog.copy(update=blog_update.dict(exclude_unset=True))
            blogs[idx] = updated_blog
            return updated_blog

    raise HTTPException(status_code=404, detail="Blog not found")

The above code looks a bit more complex than the previous ones we've written, so let’s break it down:

@app.put("/blogs/{blog_id}") route makes the update function accessible. The {blog_id} part is a path parameter that takes the unique identifier of the blog post you want to update.
blog_update: Blog: This parameter indicates that the request body should contain a Blog model with the new data to be applied.
The update_blog function iterates through the blogs list and checks for a blog post with a matching blog_id. When it finds a match, it updates that entry using the copy(update=blog_update.dict(exclude_unset=True)) method. This method updates only the fields provided in the request, leaving the others unchanged.
If the blog post is found and updated, the function returns the updated blog. If not, it raises an HTTPException with a 404 status code, indicating that the blog post was not found.

Delete Blog Post API

For this functionality, we want to allow users to remove a blog post by providing its unique identifier (UUID).

Let’s add this code to our "main.py" file:

@app.delete("/blogs/{blog_id}", response_model=Blog)
def delete_blog(blog_id: UUID):
    for idx, blog in enumerate(blogs):
        if blog.id == blog_id:
            return blogs.pop(idx)

    raise HTTPException(status_code=404, detail="Blog not found")

Let’s break down the above code:

@app.delete("/blogs/{blog_id}") as you might already know, this route provides access to the delete function. Similar to the update route, {blog_id} is a path parameter that takes the unique identifier of the blog post you want to delete.
The delete_blog function iterates through the blogs list, and if it finds a blog post with a matching blog_id, it removes that post from the list using pop(idx) and returns the deleted blog.
If the blog post is not found, the function raises an HTTPException with a 404 status code, indicating that the blog post was not found.

💡 You can access the entire code for this tutorial on GitHub.

Step 5 - Testing our APIs

To test our application APIs, start your FastAPI project server using the command below in your terminal:

(env)$ python main.py

FastAPI, by default, automatically generates API documentation without any extra setup. To access your project’s API documentation, head over to http://localhost:8000/docs#/ .

You can also test your API endpoints using the API documentation.

Step 6 - Exercise

Write an API that gets individual blogs via their id. Submit your answer as a pull request on this repository. I will give you feedback in 1-2 weeks. If you want a faster review, you can tag me on X with the URL to your pull request.

Conclusion

In this article, we learned how to build a Python API using FastAPI. We covered setting up a FastAPI project, defining the project model structure with Pydantic, implementing CRUD functionalities for our blog, and testing our APIs.

Comparing PaaS and Traditional DevOps: Choosing the Right Approach for Your Software Development Process

Daniel Adeboye — Fri, 16 Jun 2023 08:28:56 +0000

In the world of software development, there are different approaches to managing infrastructure and deploying applications. Two popular options are Platform as a Service (PaaS) and traditional DevOps processes. While both have their merits, understanding the key differences between them is crucial for making informed decisions about which approach best suits your development needs.

At PipeOps, one of our goals is to simplify the cloud deployment and infrastructure management process, and in this article, we will compare PaaS and traditional DevOps across various aspects, helping you make an informed choice.

What is Traditional DevOps?

Traditional DevOps involves the collaborative efforts of development and operations teams to streamline the software development lifecycle. It focuses on breaking down silos between teams, emphasizing collaboration, automation, and continuous integration and delivery. With traditional DevOps, developers assume responsibility for managing infrastructure, configuring servers, operating systems, and networking components to support application deployment and scaling.

What is PaaS?

Platform as a Service (PaaS) is a cloud computing model that abstracts away infrastructure management. PaaS providers like PipeOps offer a platform where developers can build, deploy, and manage applications without the need to worry about the underlying infrastructure. PaaS handles provisioning, scaling, and maintenance of the infrastructure, allowing developers to focus more on application development and deployment.

What are their differences?

Infrastructure Management: In traditional DevOps, developers take on the responsibility of managing infrastructure, configuring servers, operating systems, and networking components. On the other hand, PaaS abstracts away infrastructure management. PaaS providers handle the provisioning and maintenance of the underlying infrastructure, enabling developers to focus more on application development and deployment.
Scalability: Scaling applications in a traditional DevOps setup often requires manual intervention. Developers must provision additional servers, configure load balancers, and manage traffic distribution to accommodate increasing demand. PaaS platforms, on the other hand, offer automatic scalability. They can dynamically allocate resources based on demand, allowing applications to scale up or down seamlessly without requiring manual intervention from developers.
Deployment Process: Deploying applications in a traditional DevOps process involves configuring and managing deployment pipelines, setting up build servers, and handling deployment scripts or tools. This can be a time-consuming and complex process. PaaS platforms provide built-in deployment capabilities, simplifying the deployment process. Developers can deploy applications using a simple interface or command-line tool, abstracting away many of the deployment complexities associated with traditional DevOps.
Configuration Management: In traditional DevOps, configuration management often involves using tools like Chef, Puppet, or Ansible to manage server configurations, environment variables, and dependencies. PaaS platforms typically include configuration management capabilities as part of their offering. Developers can define application configurations and environment variables directly within the platform, simplifying the configuration management process.
Flexibility and Customization: Traditional DevOps processes provide greater flexibility and customization options. Developers have more control over infrastructure, software versions, and configurations, enabling tailored setups. PaaS platforms, while offering convenience and ease of use, may have some limitations on customization. Developers might encounter constraints when it comes to specific infrastructure configurations or software versions.
Responsibility and Maintenance: In traditional DevOps setups, developers are responsible for managing and maintaining the entire infrastructure stack. This includes security updates, patches, backups, and overall system maintenance. PaaS providers handle much of the underlying infrastructure maintenance, including security updates and backups. However, developers are still responsible for ensuring the security and maintenance of their application code.

Use PipeOps For Infrastructure Management

In this article, we have explored the concepts of PaaS and traditional DevOps, highlighting the key distinctions between them. The decision between adopting PaaS or sticking with traditional DevOps depends on several factors, such as project requirements, the level of control desired, and the trade-offs between convenience and flexibility.

PipeOps makes it easier for developer and dev-teams to deploy and manage their applications without worrying about the underlying infrastructure and with just few clicks you have everything up and ruining: try PipeOps for free now and forget worrying about the cost and risk of managing your cloud infrastructure. It only takes a minute to get started.

10 Best Deployment Platforms

Daniel Adeboye — Thu, 09 Mar 2023 13:36:53 +0000

Introduction

As businesses increasingly rely on digital platforms, the need for efficient and effective deployment solutions has become critical. With so many options available, choosing the right deployment tool can be overwhelming for developers and businesses alike. In this article, we'll explore some of the best deployment options available for businesses of all sizes, from small startups to enterprise-level companies.

In addition, we'll introduce you to PipeOps, a no-code tool for cloud deployments and infrastructure management. With PipeOps, developers can easily set up and manage their cloud infrastructure, so they can focus on building their product and serving their customers. With PipeOps, deploying your applications has never been easier.

What Is A Deployment Platform?

A deployment platform is a software tool or set of tools that automates the process of deploying software applications and services to production environments. It provides developers with a range of tools and services to quickly and efficiently deploy their applications and services to production environments. By automating the deployment process, deployment platforms help to reduce errors and speed up the time it takes to get applications up and running. This ultimately leads to faster delivery of high-quality software products to customers.

Why Are Deployment Platforms Important?

Deployment platforms are essential for modern software development, and here are four reasons why they are important:

Automation: Deployment platforms automate the deployment process, eliminating manual errors that can occur during deployment. Automation also reduces the time and effort required to deploy applications, enabling developers to focus on creating and improving software.
Consistency: Deployment platforms help to ensure consistency in the deployment process. By using standard processes and templates, deployment platforms make it easier to maintain consistency across different environments, such as development, testing, and production.
Scalability: Deployment platforms are designed to handle large-scale deployments, making them essential for businesses that need to deploy applications across multiple environments or regions. With deployment platforms, businesses can easily scale up their infrastructure to meet increasing demands, without sacrificing efficiency or reliability.
Collaboration: Deployment platforms enable teams to collaborate more effectively by providing a centralized location for managing deployment workflows, configuration files, and version control. This makes it easier for teams to work together, track changes, and ensure that everyone is working from the same codebase and deployment process.

Types Of Deployment Platforms.

As the demand for streamlined deployment processes continues to grow, there are now many different types of deployment platforms available, each with its unique features and benefits. Here are some of the most popular types of deployment platforms in use today:

Northflank

Northflank is a modern, cloud-native deployment platform designed to make deploying, managing, and scaling applications effortless. It offers developers an intuitive interface and powerful tools for building microservices, databases, and static sites. Northflank supports a wide range of programming languages and integrates seamlessly with popular version control systems like GitHub and GitLab.

With features like automatic SSL, built-in CI/CD pipelines, real-time logs, and metrics, Northflank simplifies infrastructure management while giving teams full control over their deployments. Whether you're a startup or an enterprise, Northflank helps you ship faster and manage your applications with ease.

PipeOps

PipeOps is a no-code cloud deployment and infrastructure management tool designed to simplify the setup and management of your cloud infrastructure. With PipeOps, you can easily deploy your applications and manage your infrastructure without worrying about the underlying complexities. This allows you to focus on what really matters - building your product and serving your customers.

Whether you're a seasoned developer or just starting out, PipeOps offers free plans and affordable pricing to help you get started quickly. With PipeOps, you can streamline your cloud operations and keep costs under control, so you can concentrate on delivering value to your users.

Heroku

Heroku is a cloud-based platform that helps businesses deploy and manage their applications quickly and easily. Heroku supports multiple programming languages, including Java, Ruby, Python, and Node.js.

Microsoft Azure

Microsoft Azure is a cloud-based platform that provides businesses with a wide range of services, including compute, storage, networking, and analytics. Azure supports multiple programming languages, including Java, Python, and .NET.

DigitalOcean

DigitalOcean is a cloud-based platform that provides businesses with a simple, easy-to-use platform for deploying and managing their applications. DigitalOcean supports multiple programming languages, including Java, Python, and Ruby.

Vercel

Vercel is a cloud-based platform that enables developers to deploy and manage web projects, including static and dynamic websites, APIs, and serverless functions. It supports a wide range of programming languages and frameworks, including React, Next.js, Angular, and Vue.js.

Render

Render is a cloud-based platform that provides developers with a modern, easy-to-use infrastructure for deploying web applications and APIs. Render supports a wide range of programming languages and frameworks, including Node.js, Python, Ruby, and Go.

Fly.io

Fly.io is a cloud-based platform that enables developers to deploy and manage web applications, including static websites, APIs, and serverless functions. Fly.io supports a wide range of programming languages and frameworks, including Node.js, Ruby, and Go.

AWS (Amazon Web Services)

AWS is a cloud-based platform that provides businesses with a wide range of services, including compute, storage, networking, and analytics. AWS supports multiple programming languages, including Java, Python, and .NET.

GCP (Google Cloud Platform)

GCP is a cloud-based platform that provides businesses with a wide range of services, including compute, storage, networking, and analytics. GCP supports multiple programming languages, including Java, Python, and .NET.

Netlify

Netlify is a cloud-based platform that enables developers to deploy and manage web projects, including static and dynamic websites, APIs, and serverless functions. It supports a wide range of programming languages and frameworks, including React, Next.js, Angular, and Vue.js.

Conclusion

In conclusion, deployment platforms play a vital role in modern software development. They offer automation, consistency, scalability, and collaboration, making them an essential tool for businesses looking to streamline their deployment processes. With a wide range of deployment platforms available, businesses can choose the one that best suits their needs and ensure they stay competitive by delivering high-quality products and services quickly and efficiently.

Building a Security-First Culture As A Developer or Team

Daniel Adeboye — Tue, 07 Jun 2022 11:48:19 +0000

Developing a security-first culture is crucial in today's digital age where cyber attacks and data breaches have become increasingly prevalent. As a developer or team, it may seem daunting to develop a security-first culture, but it's not that complex when put into practice. In this article, we'll list some activities that can help build a security-first culture.

Managing Secret Credentials

Using a .env file to hide secrets during development is a common practice, but it doesn't scale and doesn't improve codebase security. Using an enhanced tool like Onboardbase, a secure online vault for developers and teams to store and share app secrets, is a better and more improved option. Managing secret credentials the right way can help developers and teams reduce the rate of vulnerability in their codebase or project and create a good security culture.

Bug Hunt Session

Organizing a bug hunt session in a company can help the team discover issues fast and fix them before pushing to the general public. There are tools available to test codebase for bugs, leaked secret keys, and more. Gitguardian, for example, can scan codebase for leaked secret keys and reduce the stress of checking every single line of code in the codebase. Having regular bug hunt sessions and utilizing available tools can help foster a security-first culture.

Automate Security Initiatives

Security automation is a machine-based execution of security actions that can detect, investigate, and remediate cyber threats with or without human intervention. Security automation can identify incoming threats, triage and prioritize alerts as they emerge, and perform automated incident response. Automating security initiatives can help create a more secure and efficient work environment.

Security Awareness Training

Taking security courses and implementing security awareness training can help enlighten development teams and give them more insights on how to prioritize security when building products for themselves or the company. It is essential to put in place time and budget for taking security courses to ensure that developers are equipped with the necessary knowledge to develop a security-first culture.

In conclusion, building a security-first culture is vital to protect against cyber threats and data breaches. By following the activities listed above, developers and teams can develop a security-first culture and make it an integral part of their work environment.