Skip to main content

· 7 min read
Mateusz Szostok

Our first blog post focused strongly on why—why we created Capact, what's the general concept behind it. Now it's time for showing how—how you can use it.

Although, there are many ways to get started with Capact, today we will focus on your perspective as a Capact User.

The recommended way to try out Capact quickly is to set up a local environment.

# Create local k3d clustercapact env create k3d# Install Capactcapact install# Log in interactively to the Capact Gatewaycapact login https://gateway.capact.local# You're all set! Enjoy using Capact!

Detailed instructions are already nicely described in our local installation tutorial. Once you have Capact up and running, we can start!

· 10 min read
Mateusz Szostok
Paweł Kosiec

Did you know that it's already been 16 months since Capact was born?

In a previous blog post, we discussed some of the problems Capact aims to solve. This time, Capact maintainers took some time to answer questions you might have if you're considering contributing to the project.

What's it like to build a cloud-native platform from scratch? What is it like to work in Capact? What are the biggest challenges? How to start with Go? Read on to get the answers!

· 7 min read
Paweł Kosiec

Managing the lifecycle of infrastructure, applications, and processes in modern IT is problematic. There are a variety of tools and best practices, which are ever-changing. It's a struggle to stay up-to-date with these practices, and not everyone is an expert at everything. Technical debt is inevitable.

We are ultimately all alone. We are siloed within the context of team, department, or company, locked-in in a particular ecosystem of tooling. To deliver end-to-end capabilities, we build them from scratch in a vacuum. We consume API calls, transform data, build and manage infrastructure and applications. Don't we spend too much time solving the same problems as others have?

Sharing expertise is something that already happens—we have plenty of libraries and frameworks out there. But what if we went a step further and have a way to create, use and share building blocks that are language-agnostic abstracted capabilities?

For example, if you're not a cloud expert, all you need to know is that you want a managed PostgreSQL database on AWS. Let the subject-matter experts take care of it, and simply focus on your business logic. Likewise, if you need any Kubernetes cluster—by saying "I want any Kubernetes cluster" and letting the magic happen, you could cover both local development and production scenarios…

What if I told you… now this is all possible?