DEV Community: Tuomas

Easily Create Complex Stacks in Just a Few Clicks — New Release!

Tuomas — Mon, 17 Mar 2025 14:06:52 +0000

Previously, we wrote about our IaC implementation, and today we are proud to announce its public release. Our new Stack Builder is out for anyone to try out! 🎉 Head over to diploi.com to have a go with it.

Here's a concise list of what this new update makes possible:

🖱️ Pick 'n' choose style UI for creating tech stacks
🔌 Zero-config deployments for even the most challenging of stacks
🪄 Automatic monorepo generation & configuration
🔥 Automatic image generation for optimized production deployments
🔧 Access to Dockerfiles for each component for full customizability

These are in addition to what Diploi already offers, like our remote development environments with Cloud IDE & SSH support and automatic SSL generation to name a few.

Below is a deeper dive to some key highlights of this update. I'll also reveal a few behind the scenes details on how we implemented these features 😉, so keep reading if you are interested!

🏗️ Visual Stack Builder

Before this update, we supported a list of pre-made stacks with services that could not be easily swapped out for others. Like a template with Next.js and PostgreSQL could not be easily changed to include Redis for example. The most common feedback we received (by far) was the lack of support for the exact stack someone was familiar with and wanted to use. So we set out to fix this issue (and the solution had to be magical 🪄).

What we ended up implementing is a one of a kind tool for easily building the exact stack that your project needs while still remaining flexible once the project grows or changes in scope. Our Stack Builder combined with the IaC diploi.yaml file allows you to change infrastructure on the fly, and because the file is committed to Git, even maintain different infrastructure on different branches 🤯!

A visual list of components that can be easily included in the stack.

Once you have picked your ideal stack, here's what our system does behind the scenes:

Creates a monorepo with boilerplate code for each component
Preconfigures GitHub actions to create optimized production builds
Generates HELM charts to set up environments with
Generates domains & SSL certificates for component endpoints

👀 We also implemented an embedded version of the full stack builder on our diploi.com homepage. You can launch a stack directly from it without even creating an account. Give it a try if you are interested!

📝 Infrastructure as Code (IaC)

I won't go into too much detail here, as you can check out the IaC implementation blog post that goes into great detail about our IaC implementation.

I do want to give an example of the diploi.yaml file here to give you an idea of what our Stack Builder actually generates as an output.

diploiVersion: v1.0
components:
  - name: Next.js
    identifier: next
    package: https://github.com/diploi/component-nextjs#v0.0.1
    env:
      include:
        - postgres.*
addons:
  - name: PostgreSQL
    identifier: postgres
    package: https://github.com/diploi/addon-postgres#v17.0

An example Diploi config produced from the visual component picker.

This file is committed to your repository, and can be changed at any time. It makes managing your infrastructure as easy as installing an NPM package.

⚙️ GitHub Actions

While giving our users the freedom to edit their stacks the way they liked, we still wanted to give them the most optimized production environments possible, which means building optimized Docker images.

We wanted to use GitHub actions for this task as GitHub actions make it convenient to run CI/CD tasks (like building production ready images) right in the project repository, and a lot of developers like using them in their workflow.

We created two custom GitHub actions to make this as easy for the user as possible:

A "Define Components" action that reads the diploi.yaml file directly from the repository and builds a list of components that need to have images built
A "Build" action that configures and builds a single component

We then create a matrix step from the output of the Define Components action, which allows us to run the Build action for each of the components. This way we do not need to edit the GitHub actions file at all even when the components change!

An example of our two GitHub actions working together to build all the component images for a single repository.

We allow customizing the Dockerfiles for each of these components directly inside of the project repository, so you can tweak these builds to your liking.

Both of these actions are actually open source, so check them out at our GitHub:
👉 diploi/action-components
👉 diploi/action-build

That's all we have for now! If you have any questions, feel free to leave a comment on this post 🙏.

And check out our new Stack Builder directly on diploi.com!

How We Solved Infrastructure as Code

Tuomas — Tue, 03 Dec 2024 09:23:38 +0000

Infrastructure as Code (or IaC for short) has been gaining traction recently—and for good reason. It brings with it a ton of benefits, but can often be challenging to get started with. Many cloud services still lack support for it, forcing users to navigate a maze of control panels to make changes to their infra.

At Diploi, we looked at existing solutions such as Terraform, Pulumi, AWS CloudFormation, and Azure ARM Templates but found that none fully aligned with our motto of providing a "magical development experience". While these tools are highly versatile and capable of handling almost any infrastructure configuration, they are often difficult to master and excessively verbose. Setting up a single service often requires creating multiple templates and configuration files.

As that was not the developer experience we were looking for, we decided to build our own easy-to-use IaC solution.

What is Infrastructure as Code?

For developers, Infrastructure as Code (IaC) essentially means replacing cloud provider management dashboards with config files. These files contain everything necessary to replicate a specific environment, ensuring that the environment your code runs on is always set up correctly and consistently.

Typically, your IaC definitions would specify the following:

Deployment Target: Where your code will be deployed, such as AWS or Azure.
Required Services: The services needed to support your application.
Virtual Machine Setup: Configuring any necessary VMs and installing dependencies.
Network Configuration: Setting up & securing the network. Provisioning domain names. Configuring DNS.
Application Execution: Deploying and running the application code.

Our Implementation

We thought a lot about the best way to implement IaC into Diploi. Our solution had to be intuitive, developer-centric, and highly customizable.
We settled on a component-based model that allows users to easily configure their stack without making the config overly verbose. The more detailed config for a component, such as HELM charts and other setup files, are housed in dedicated GitHub repositories maintained by the component owners.
However, users can also specify local path for a component, enabling custom components to be seamlessly inlined within the projects repository.
This approach gives our users the best of both worlds: a simple, easy-to-use config combined with limitless customization options, including custom Docker files, HELM charts, and more.

diploiVersion: v1.0
components:
  - name: Next.js
    identifier: next
    package: https://github.com/diploi/component-nextjs#v0.0.1
  - name: Local
    identifier: local
    package: ./local-package
addons:
  - name: PostgreSQL
    identifier: postgres
    package: https://github.com/diploi/addon-postgres#v17.0

A simple Diploi config capable of replicating a complex environment.

These simple config files, combined with our intuitive Stack Builder, create a developer experience within Diploi that is magical ✨ and unparalleled.

Benefits of Our Implementation

Our implementation in Diploi comes with a long list of benefits, many of which are true for any IaC system. Here are some of the more interesting ones in a easily digestible list:

Versioning with Git 🌳
- Maintain separate infra in different branches
- Diffs & blames for infra changes
Self-Documenting Config Files 📝
- View all infra components in a single file
- Clickable links to find information on each component
Inlining Components 🏠
- Include component config files directly in the local repository
- Permanent version pinning and customizations

We’re still working on our system, so stay tuned for a more detailed explanation in the future. 😉

By the way, we’re currently looking for developers to join our internal testing program. If you’re interested in trying out our version of IaC before its official release, leave a comment, and I’ll get in touch!

Diploi Stack Builder

Tuomas — Wed, 06 Nov 2024 11:17:59 +0000

In our previous blog post we opened up our future plans in the form of a roadmap. We also promised to write more detailed posts on each item, and this post is the first.

What is a Stack Builder?

Diploi, our tool to run development & production environments, needs to know the infrastructure for each environment. Until now, someone needed to manually create a template with example code, HELM charts, and everything else Diploi required in order to work. This was quite hard if you had never worked on HELM or Kubernetes before. We want to make it easy for everyone to build a custom tech stack in seconds, without previous knowledge of Kubernetes or Diploi.

Enter the Stack Builder.

How it Works

When you open the builder, you'll get a list of official and community made stacks that are ready to use and include working example code. If you pick one of these pre-made stacks, you can still modify them with extra add-ons like databases and services.

If you need more control, you can switch to a custom stack, where you may pick all the components yourself.
For example, you could pick a stack with Node.js front-end and a Laravel backend with a PostgreSQL DB and a Redis cache. All pre-configured and ready to go with a few clicks.

After you have made your selection, Diploi will build a monorepo for your with all the required code to get you started. With one click, you have a ready-to-go remote code environment with the stack you just built.

How it Works on a Deeper Level

As you create your stack, we compose a diploi.yaml file for you. This will include all the components and add-ons for your stack, and some neat configuration to import & export env values and so on. This file can be updated in your code editor, and your infrastructure will automatically adapt to the changes. This means that environments in Diploi are fully configured as code.

As we create the monorepo, we also include GitHub actions to build your components, HELM charts to run the internal Kubernetes cluster, setup the required packages for your development environment, and so on.

When Can You Test It?

We are currently working with a small internal testing group to iron out the experience. We aim to have a public beta up and running by the end of the year, so keep your eyes open!

🗺️ Diploi Roadmap for 2024

Tuomas — Thu, 03 Oct 2024 13:28:37 +0000

We’ve been hard at work building Diploi, and now that we got funded 🎉, the pace is only going to accelerate!

Many of you have been asking for a roadmap, and we hear you!
Below is a list of features, prioritized by importance, that will be coming in the near future. We will be publishing a dedicated article for each one, starting with the Stack Builder in the coming weeks.

1. 🧰 Stack Builder

A pick-and-choose-style tech stack builder
Easily combine different components to create any stack
Choose a pre-made stack with example code and add your own addons

2. 📝 Configuration-as-Code

Share a Diploi project simply by sharing its repository
Modify your entire infrastructure with code
Easily maintain different infrastructure setups on different branches

3. 🌍 Community Stacks

One-click sharing of pre-made stacks with example code
Access a constantly expanding library of community-made stacks for any occasion
Get rewarded when your shared stacks are used by others

4. 🔮 Future

Status monitoring, history and alerts
Improved logging
Cloud-agnostic deployments and self-hosting options

That’s a wrap for what's currently in our pipeline! 🙏 We can't wait to get these features in your hands. If you’d like to be part of a closed group of testers, let us know! We’re always looking for developers eager to try out new features.

Astro with PostgreSQL

Tuomas — Tue, 27 Feb 2024 10:26:13 +0000

Astro is a simple yet powerful front-end framework for content-driven websites. The common way of building websites with Astro involves getting dynamic data from an external CMS or API. If you do not need a fully fledged CMS, but would still like to dynamically change some content on your Astro site, all you might need is a PostgreSQL database.

Getting Started

I will be using Diploi to bootstrap this project. Diploi comes with an Astro project and PostgreSQL DB pre-configured, so no setup required. Simply choose the "Astro" template when creating a new project.

You can also follow the manual installation guide on the official Astro documentation. It can be found here: https://docs.astro.build/en/install/auto/.

In both cases, you will get an example project with a single demo page. We will continue from there.

Connecting to a PostgreSQL DB

Let's get our Astro page to talk with PostgreSQL. First thing we need to do is to install the node-postgres (or "pg" for short) library from NPM. We will use this client to query our PostgreSQL DB.



npm i pg
npm i --save-dev @types/pg

If you do not plan on using TypeScript, you can leave out the @types/pg package.

The Diploi Astro template comes with an optional PostgreSQL database, with ENV variables pre-configured. If you are not using Diploi, you may specify different ENV variables, or handle the configuration is some other way.

Here are the ENV variables Diploi gives us by default:



POSTGRES_HOST
POSTGRES_PORT
POSTGRES_DB
POSTGRES_USER
POSTGRES_PASSWORD

Create a db.ts file in the /src folder:



import pg from 'pg';

// Make sure we DO NOT "prerender" this function to allow the ENV variables to update on the fly
export const prerender = false;

const client = new pg.Client({
  host: import.meta.env.POSTGRES_HOST,
  port: import.meta.env.POSTGRES_PORT,
  database: import.meta.env.POSTGRES_DB,
  user: import.meta.env.POSTGRES_USER,
  password: import.meta.env.POSTGRES_PASSWORD,
});

await client.connect()

export { client as db };

This file will initialize our DB client, so we can use it in any Astro component!

Let's create an example component that queries the current time from the DB. Create a DB.astro file in the /src/components directory:



---
import { db } from '../db';

const { rows } = await db.query('SELECT NOW() as "time"');
---

<time>{rows[0].time}</time>

This component will connect to the PotsgreSQL DB, query the current time with NOW(), and finally render it on the page!

Try it out by adding it to the /src/pages/index.astro page. At the top, import the component with:



import DB from '../components/DB.astro';

And then include it anywhere on the page with:



<DB />

Wherever you placed you component, you should see a timestamp that updates on each page load!

That's It?

You can see how simple it is to talk to the DB directly, no HTTP API needed! This way you could use your PostgreSQL DB as a simple CMS, or just have some information easily changeable without code changes.

This data is not as dynamic as it may seem though. In development mode, Astro will query this data every time the page is loaded. In production, however, Astro will create a static build that will not query the DB on every page load. It only queries it once when the production build is made. If you do need the data to be updated dynamically, you can do so by enabling the fairly new SSR support in Astro.

Enabling SSR in Astro

SSR, or server-side rendering, means on-demand rendering on the server when a page is requested. This means that Astro will not build a static HTML version of your entire site, but acts more like a PHP server that builds the page on-demand when a user visits it.

On Diploi, the only change you have to make is a single line in your index.astro page:



export const prerender = false;

By exporting this line right after any import statements, we tell Astro to opt this page out of static rendering, and to render it on demand whenever a client requests it.

If you are not using Diploi, you will have to configure an SSR adapter for your Astro project. You will find a guide to do so in the official Astro documentation at https://docs.astro.build/en/guides/server-side-rendering/..

Diploi?

I have mentioned Diploi quite a few times in this blog post. Diploi is a single SaaS service for managing, developing and hosting your full application. We have been building Diploi for a while now, and would love for you to have a go (for free of course)!

Trying new frameworks is as-easy-as clicking a single button on Diploi, so you can focus on the fun parts, not the setup.

Check us out at https://diploi.com/