Frequently Asked Questions
Serverless is a term applied to a new generation of platforms where virtual and physical servers are completely abstracted for end users. In essence, serverless platforms provide autoscaling, high availability and fault-tolerance, thus removing the need for developers to think about servers.
MicroVMs are lightweight virtual machines.
The virtualization technology we use to run your containers, Firecracker, offers a lot of advantages in term of security and performances. You can learn more about Firecracker on our blog:
- Firecracker MicroVMs: Lightweight Virtualization for Containers and Serverless Workloads (opens in a new tab).
- 10 Reasons Why We Love Firecracker MicroVMs (opens in a new tab)
Koyeb is a serverless platform built from the ground up by the Koyeb engineering teams. We rely on many open-source technologies that we love to write about on our blog (opens in a new tab).
We also speak regularly about our technological stack at various events and we provided the full overview at Equinix's 2021 proximity event (opens in a new tab).
You can decide where your applications will be hosted. We provide core locations in Europe and North America.
We use different Cloud Service Providers depending on the core location you select. The list can be found in our Data Processing Agreement.
Our core locations can run on any Cloud Service Provider. Koyeb also supports edge and on-premise deployments for Enterprises workload. Please contact us if you have such a need.
All of your apps and services are running on top of bare metal servers with high-end CPUs. Paid containers receive a share of CPU with at least 0.25 dedicated vCPU per GB of memory and can burst to full speed with all the cores exposed to the container.
With the startup plan, you can use up to 32GB at the same time which is equivalent to 128 nano containers. Contact us if you need more!
You can tweak the number of connections your container accepts. There is no vertical scaling required, simply select the right container size for your app.
PostgreSQL databases are currently available in public preview. You can try them out for free during this period to help us fine-tune our offering. Please use with caution and do not rely on it for critical operations.
Alternatively, you can use a DBaaS provider. If you need some guidance, we discuss several providers in our blog post on choosing a database platform (opens in a new tab) which can be used in combination with Koyeb.
We block all outbound traffic on port 25, typically used for plaintext mail delivery with the SMTP protocol, to mitigate spam. If you need to use SMTP, consider using port 587 for encrypted transmission.
I want to restrict access to a database or other application by IP address. What IP addresses does Koyeb use?
We do not currently provide a list of static outbound IP addresses that your Services may be deployed to. There is an open request for listing outbound IP addresses (opens in a new tab) on our feedback platform where you can follow progress and share your interest.
In the meantime, you can obtain Koyeb's current IP ranges on a per-region basis. To do so, check the DNS information associated with the region-wide domain names using the following naming pattern:
For example, to find the current IP addresses associated with the Frankfurt region with
The output will look similar to this:
; <<>> DiG 9.18.17 <<>> all-fra1.infra.prod.koyeb.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4453 ;; flags: qr rd ra; QUERY: 1, ANSWER: 12, AUTHORITY: 0, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;all-fra1.infra.prod.koyeb.com. IN A ;; ANSWER SECTION: all-fra1.infra.prod.koyeb.com. 300 IN A 18.104.22.168 all-fra1.infra.prod.koyeb.com. 300 IN A 22.214.171.124 all-fra1.infra.prod.koyeb.com. 300 IN A 126.96.36.199 all-fra1.infra.prod.koyeb.com. 300 IN A 188.8.131.52 all-fra1.infra.prod.koyeb.com. 300 IN A 184.108.40.206 all-fra1.infra.prod.koyeb.com. 300 IN A 220.127.116.11 all-fra1.infra.prod.koyeb.com. 300 IN A 18.104.22.168 all-fra1.infra.prod.koyeb.com. 300 IN A 22.214.171.124 all-fra1.infra.prod.koyeb.com. 300 IN A 126.96.36.199 all-fra1.infra.prod.koyeb.com. 300 IN A 188.8.131.52 all-fra1.infra.prod.koyeb.com. 300 IN A 184.108.40.206 all-fra1.infra.prod.koyeb.com. 300 IN A 220.127.116.11 ;; Query time: 28 msec ;; SERVER: 10.51.1.2#53(10.51.1.2) (UDP) ;; WHEN: Mon Jul 31 12:43:25 CEST 2023 ;; MSG SIZE rcvd: 250
Similarly, for the Washington D.C. region, you would type:
Note: Please keep in mind that IP addresses may be added or removed from the pool without notice. If you are relying on these addresses for populating an allow list for another service, you will have to recheck and update the values periodically.
You are probably already using multiple cloud providers!
We see two main cases where organisations use multiple Cloud Service Providers:
- De facto: Many companies use multiple cloud service providers because different teams, departments, or projects have different needs. Larger enterprises often inherit heterogeneous infrastructure across multiple providers through mergers and acquisitions.
- Strategically: Often, companies have a strategic need to use multiple Cloud Service Providers. This might be for cost reasons, availability, performance, or because their own customers want to run on different Cloud Service Providers.
Most companies fall into the first category. The term multicloud is often interpreted as using multiple cloud service providers at the same time and for the same workload. Most of the time, however, multicloud is about embracing multiple Cloud Service Providers for different features and needs.
We consider the three main reasons in which organisations define a strategy to use multiple Cloud Service Providers to be:
- Features and efficiency: Cloud Service Providers do not all offer the same product. Some Cloud Service Providers are specialized in AI workloads whereas others provide efficient compute servers. There is also a rise in specialized providers with APIs targeting specific domains. These features might significantly improve time to market and enable new business cases.
- Price: Different cloud service providers have price differences which can lead to significant differences in spend for services in the same category. In some cases, choosing certain Cloud Service Providers can enable business cases not economically viable elsewhere.
- Availability and Performance: Cloud Service Providers offer a variety of performance levels and have different regional availability. Some companies need to combine multiple Cloud Service Providers for compliance reasons or for performance reasons.
This is a short overview of the reasons that lead to multicloud setups.
In event-driven processing, any action in your information systems and business can trigger a real-time task. Event-driven architectures are designed to enhance horizontal scalability and distributed processing.
Read more about event-driven architectures in our blog post about event-driven architectures (opens in a new tab).