Infrastructuur en platform

Jouw omgeving, jouw knoppen: waarom wij ons eigen portal en API's bouwen

Onze klanten beheren hun complete hostingomgeving zelf. Of het nu gaat om één WordPress-site op ons shared platform of een volledig cluster met meerdere load balancers, webservers en databaseservers: alles is door de klant zelf te bedienen, vanuit hetzelfde portal en dezelfde API. Geen mailtjes sturen, geen tickets openen, niet eerst iets in een git-repo committen en dan maar afwachten. En dat is in de managed hosting wereld een stuk minder normaal dan je zou denken.

Wie we zijn

DevNomads is een klein team dat managed hosting en infrastructuur levert, volledig in eigen beheer. En dat bedoelen we vrij letterlijk. Het internet is eigenlijk een verzameling van tienduizenden netwerken die met elkaar praten, en elk van die netwerken heeft een eigen nummer: een ASN (Autonomous System Number). De meeste hostingbedrijven huren ruimte in het netwerk van een ander. Wij niet: we zijn RIPE LIR, hebben ons eigen AS-nummer en onze eigen IP-adressen. Voor het internet zíjn wij dus een van die netwerken, geen huurder bij iemand anders. Alle hardware, netwerkapparatuur en servers zijn van onszelf en draaien in het Eurofiber Cloud Infra datacenter in Steenbergen.

Ook de software bouwen we zelf. Ons klantportal (portal.devnomads.nl) en onze publieke API (api.devnomads.nl) zijn in-house geschreven in Laravel. Daaronder zit onze eigen infra-api, geschreven in Python, die de daadwerkelijke servers, websites en containers aanstuurt. Het portal en de publieke API praten tegen die infra-api, en die regelt het vervolgens op onze hypervisors en platformen, die we ook zelf gebouwd hebben. Geen kant-en-klaar cloudpaneel ertussen, de hele keten is van ons.

Het probleem met standaardpanelen

Wil je van ons een server met Plesk of DirectAdmin? Die krijg je gewoon, daar is niks mis mee. Maar wij hebben er zelf een probleem mee: als een klant vraagt "kan x of y?", is het antwoord met zo'n standaardpaneel altijd "misschien, maar alleen als DirectAdmin of Plesk het ondersteunt". Je zit vast aan de roadmap van een ander.

En bij managed hosting is het vaak nog beperkter. Managed betekent bij veel partijen: wij beheren het, dus jij mag er niet aan. Elke aanpassing gaat via een mailtje of een ticket, en dan is het wachten tot iemand er tijd voor heeft. Handig voor de hoster, minder handig voor jou.

Hoe wij het doen

Met onze eigen stack is het antwoord op "kan dat?" meestal gewoon "ja". Er is bijna niks dat we niet zelf kunnen bouwen, van een knop in het portal tot een aanpassing diep in de infrastructuur.

Belangrijker nog: die vraag hoef je vaak niet eens te stellen. Óók onze managed klanten hebben volledige controle over hun eigen configuratie, via het portal of via de API. Shared hosting en managed omgevingen draaien bij ons op vrijwel dezelfde stack, dus je beheert alles op dezelfde manier, vanaf dezelfde plek. Eén site of een compleet cluster, voor ons maakt het niet uit. Wij zorgen dat het onderliggende platform gezond is, jij bepaalt wat erop gebeurt. Dat is de kern van hoe wij werken: we maken onze klanten autonoom.

Eerlijk is eerlijk: alles zelf bouwen is ook gewoon veel werk. Maar het betekent wel dat wíj bepalen wat er kan, en niet een leverancier.

Portal, API of CLI, wat jij handig vindt

Iedereen werkt anders, dus we bieden dezelfde knoppen op drie manieren aan.

Het portal is de plek voor de dagelijkse dingen: even een mailbox aanmaken, een DNS-record aanpassen, kijken hoe je site ervoor staat. De API is er voor wie wil automatiseren: alles wat in het portal kan, kan ook via api.devnomads.nl. En voor in je terminal of je deploy-pipeline is er onze CLI, gewoon te installeren via PyPI als devnomads-cli.

Hoe dat er in de praktijk uitziet? Een webbureau zet een nieuwe klantsite live door in het portal een site aan te maken en de PHP-versie te kiezen, en laat vervolgens de pipeline het werk doen: bij elke release deployt de CLI de nieuwe code automatisch naar ons platform. Geen FTP, geen ticket, geen mailtje met "kunnen jullie dit even klaarzetten". De developer richt het één keer in en daarna loopt het gewoon.

Wat je daar concreet aan hebt

Een paar voorbeelden van wat je vandaag zelf regelt, zonder ticket:

  • Domeinnamen registreren, DNS-records beheren en DNSSEC aanzetten, direct vanuit het portal.
  • Mailboxen aanmaken, het spamfilter beheren en zelf de quarantaine inzien, inclusief gedeelde agenda's en adresboeken.
  • Een website met één klik van WordPress voorzien, de PHP-versie wisselen, cron jobs instellen en live meekijken in je logs.
  • Je database beheren, inclusief bijvoorbeeld het aanzetten van PostgreSQL-extensies.
  • Je VM herstarten, snapshots maken en de console bekijken, gewoon vanuit je browser.

En omdat portal, API en CLI allemaal tegen dezelfde backend praten, maakt het niet uit waar je iets aanpast. Wat je in de pipeline deployt, zie je in het portal terug.

Ontwikkeling

Het platform is nooit af, en nieuwe features staan bij ons niet jaren op een roadmap. Zo bouwen we nu aan het live aanpassen van CPU-cores en geheugen op VM's zonder herstart, en aan het direct instellen van een nieuw root-wachtwoord of SSH-keys in een draaiende VM. Ook backups zelf terugzetten vanuit het portal is de volgende stap in self-service.

Klaar voor AI

Maar de grootste beweging is een andere: AI-agents gaan niet meer weg. Steeds vaker is het niet een developer die op de deploy-knop drukt, maar een AI die namens die developer werkt. Daar bouwen we hard aan: alles wat zo'n agent nodig heeft om de codebase van een klant op ons platform te deployen moet er gewoon zijn, netjes en machine-leesbaar. En juist dáár betaalt die eigen stack zich uit: een platform dat je zelf gebouwd hebt, kun je ook zelf agent-klaar maken. Met een standaardpaneel was het antwoord weer "misschien, als de leverancier het ondersteunt" geweest.

Benieuwd of dit ook voor jouw situatie werkt? Stuur ons gewoon een berichtje, dan kijken we mee.