Contact us


Diverse software stack support

We support a wide variety of programming languages and platforms. This is possible thanks to our:

  • Thoughtful approaches

    Maintaining infrastructure and interacting with developers, we follow the best practices that are effective regardless of the software platforms in use.

  • Universal technologies

    The technologies and tools that we use allow us to adapt CI/CD processes to any workflows, implement them with applications written in any programming language, run them in various data centers and clouds.

  • Experience and open-mindedness

    While we've been dealing with a huge number of diverse applications & platforms for many years, we've been always sharing the knowledge gained between our DevOps teams. Meeting the changing market needs, we are always open to new languages, platforms, and patterns chosen by developers.

Obviously, this variety constantly changes since we follow the principle of continuous learning and are able to quickly adapt to new technologies. 

Compatibility with your projects

Is your app ready for transformation?

There is a well-known standard called Twelve-Factor. It describes the methodology for building web applications based on services. Ideally, the application should fully comply with it. However, in practice, you may sacrifice some requirements in the short term. Several key specifications that are worth paying attention to are listed below:

  • SCM and CI

    The codebase should be stored in Git. We support all popular software configuration management (SCM) and continuous integration (CI) systems including GitLab & GitLab CI, Bitbucket & Bamboo, GitHub & GitHub Actions, Jenkins,, Travis CI, Circle CI, etc.

    Stateless vs. stateful

    An application that does not store internal state (i.e. stateless) is much easier to manage. However, this is not a critical obstacle. It's possible to have a stateful app as well but it's important to keep in mind that this will require more commitment.

  • Configuration

    There are many ways to configure an application. The most common are using environment variables and config files. What’s important is that the configuration should not be buried deep inside the source code — it should be easily accessible providing an ability to configure everything in one place.

    Other requirements

    The remaining requirements for logging and other aspects of application’ activities are also important. Our experience shows that they do not cause substantive issues. Typically, they are quickly resolved.

  • Separation of stages

    It is important to separate build, release and run stages. At the build stage, a universal image should be created that runs in any of runtime environments. Configuration for the environment should be applied at the time of release. You can build different images for different environments, however, such an approach entails a significant risk of unexpected bugs. This is due to differences between what you test and what you run.

Your app doesn't meet the requirements?

We do not limit the initial state of the app by our requirements. We are ready to support the project in its current state and immediately provide guarantees under our standard service-level agreement (SLA).

At the early stages of our cooperation, we fix crucial issues and modernize infrastructure, enabling it to meet the high-quality standards. When it's done, we can offer individual conditions under the enhanced SLA.

What do developers need to know?

Developers aren't required to have any specialized knowledge for both creating a new app or improving an existing one. It's our team of DevOps engineers who is in charge of implementing CI/CD processes, building & maintaining the infrastructure and solving any related issues.

This infrastructure will be based on several well-known Open Source projects including Kubernetes, Helm, and werf (applications configuration is based on Ansible). Learn more about our typical tech stack here.

Real-life examples from our experience

  • Dozens of microservices

    One of our projects had 50+ Go applications interacting with each other via gRPC. We have unified the building and deploying mechanisms, so the process of introducing of new services into the cloud has become as easy as copying a single file.


    We have gone through many blockchain-related projects working with Bitcoin Cash, Litecoin, Grin, Ripple and others. Many of them had specific pitfalls. For example, Java-based IOTA forced us to get in touch with the community of developers so we could connect to the network as a node. The other notable case is linked to Ripple whose developer is known for neglecting DEB packets, so the only way to run it in Ubuntu is using alien… Moreover, Bitcoin forks contain huge databases what places exceptional requirements on hard drives: in case of any disks' failures, the daemon starts the database rescan which could easily last for 3-4 days.

  • Sophisticated CI/CD processes

    It's hardly surprising that sometimes you have to implement nontrivial CI/CD solutions. For example, sometimes we need to generate changes in other repositories (say, in the docs) when making modifications to the current one. This, in turn, will launch its own CI processes like tests, reports, etc.

    Developing on Kubernetes

    Developers (especially those who prefer interpreted programming languages) would like to make quick changes in the code (in their preferred IDE) and to see the results instantly (simply by pressing F5), without having to wait while its building/deploying is finished. We have tested different solutions for Kubernetes and ended up using Telepresence for local development — it works like a charm!

  • JMeter Cluster with autoscaling

    We have implemented load testing with JMeter in the Kubernetes cluster. It was even more complicated due to a requirement of using its GUI mode (via X server). In addition, we had to connect JMeter's master and slave  nodes that was not trivial given the scaling capabilities.

    Geographically distributed clusters

    Some projects are truly global and need to be available on different continents. In such circumstances, the issue of data consistency arises. Dealing with distributed clusters, we have implemented the rapid deployment of test environments with relevant data populated, simultaneous deploy to several clusters and much more.