GATEs hosting kör din app utifrån en gate.json-fil i dess repo: Bun, Node 20, PHP 8.2 eller din egen Dockerfile, med PostgreSQL 16 till 18, MySQL eller MongoDB, Redis, S3-kompatibel lagring och dina egna domäner med HTTPS. Varje push till driftsättningsgrenen går live, migreringarna först, och sparas som en signerad release på servrar i Tyskland och Finland. Inget GitHub-konto? GATE håller koden i ett privat repo åt dig.
Inga servrar att hyra, ingen pipeline att bygga och inga certifikat att jaga. Du tar med koden och en konfigfil, och GATE kör allt under den.
Peka GATE mot ditt GitHub-repo, godkänt en gång av en ägare av er GitHub-organisation, eller låt GATE skapa ett privat repo åt dig. Det kan flyttas till din egen GitHub senare.
En gate.json i repot namnger dina tjänster och vad de körs på, Bun, Node eller PHP, eller din egen Dockerfile, och om du vill ha en databas, en cache, fillagring eller egna domäner.
Containrar, portar, routes och HTTPS-certifikat genereras ur den filen och hålls utanför ditt repo, så de glider aldrig isär från din kod.
Varje push till din driftsättningsgren skeppas: koden hämtas, migreringarna körs innan tjänsten startar, och driftsättningen sparas som en signerad release och loggas med sin commit och hur lång tid den tog.
Varje tjänst får en hälsokontroll på sin egen port, och en som inte klarar den två gånger i rad startas om automatiskt.
Allt som körs genereras ur ditt repo, så det levande systemet kan inte glida iväg från din kod.
Vem som än pushar, en person eller din agent.
Ett ord eller två i gate.json för varje, kopplat till dina tjänster automatiskt.
PostgreSQL 16, 17 eller 18, med vektorsökning när du behöver det, eller din egen image som TimescaleDB. Datan ligger på disk bredvid sajten, aldrig öppen mot internet.
Deklarera en cache så får varje tjänst dess adress, utan något att klistra in.
Publika eller privata buckets, skapade vid varje driftsättning och sparade som vanliga filer bredvid databasen, med nycklarna injicerade i dina tjänster.
Lista en domän på en tjänst så routar GATE den med ett certifikat, eller ge varje kund en egen subdomän. Ta bort en domän ur filen så tas dess route ner.
En rad ger din app en mejlfångare: mejlen den skickar hamnar i en inkorg du öppnar i webbläsaren, inte hos riktiga personer.
En frontend och en backend i separata repon driftsätts som ett system, med en gemensam databas och en gemensam cache.
Tre sätt att få en app på nätet, sida vid sida.
| Det du jämför | En egen server | En hostingplattform | GATEs hosting |
|---|---|---|---|
| Uppsättning | Installera och patcha allt själv | Koppla ett repo och ställ in plattformen | En gate.json i repot, som din agent kan skriva |
| Databas | Du installerar och sköter den | Ofta en separat tjänst att koppla in | Deklarerad i gate.json, uppgifterna ifyllda |
| Driftsättning | Skript du skriver och håller igång | Vid push, inställt per plattform | Varje push till driftsättningsgrenen, migreringarna först |
| Vem som sköter den | Du | Du, via plattformens dashboard | Din agent sätter upp, driftsätter och läser loggarna |
| Var den körs | Där du hyr | Plattformens regioner | GATEs servrar i Tyskland och Finland |
Berätta för din agent vad appen behöver och var den ska ligga. Den skriver gate.json, sätter upp sajten och driftsätter den, och när en driftsättning misslyckas är det den som läser loggarna.
Möt dina agenterNej. Med GATE kopplar ett företag ett repo, eller låter GATE hålla ett, och beskriver vad appen behöver i en gate.json-fil. Servrar, databasen, nätverket och HTTPS-certifikaten är GATEs sida av gränsen, på GATEs servrar i Tyskland och Finland, och den genererade infrastrukturen ligger utanför repot och byggs om ur det vid varje driftsättning.
Nej. Ett företag utan GitHub får ett privat repo som GATE skapar i sin egen GitHub-organisation, med åtkomst till just det repot och inget annat. Driftsättningar fungerar som för vilket annat repo som helst. När företaget vill ha koden på ett eget GitHub-konto flyttas repot dit, och GATE pekar om sajten till den nya platsen.
Varje push till driftsättningsgrenen driftsätts, sammanslagna pull requests inräknade. GATE kontrollerar GitHubs signatur på pushen, hämtar koden, kör migreringarna innan tjänsten startar, bygger om containrarna, sparar driftsättningen som en signerad release och loggar dess commit och hur lång tid den tog. En manipulerad eller osignerad release stoppas innan något startar.
Som standard backar du committen och pushar: allt som körs i GATE genereras ur repot, så när repot flyttas tillbaka flyttas appen tillbaka. En sajt som följer GATEs stabila spår kan också backa till den senaste stabila releasen med ett kommando, om ingen migrering emellan är markerad som oåterkallelig; då rättas felet framåt i stället.
GATE genererar imagen för Bun, standardvalet, Node 20 eller PHP 8.2 med Apache, med Vite, Next.js, Remix eller en vanlig server, plus extra systempaket eller PHP-tillägg när appen behöver dem. Alla andra stackar körs från repots egen Dockerfile och får samma domäner, HTTPS, hälsokontroller och sajthemligheter som en genererad image.
PostgreSQL, MySQL eller MongoDB. I GATE är PostgreSQL version 16 som standard och kan låsas till 17 eller 18, ha vektortillägget för AI-funktioner eller köras från en egen image som TimescaleDB. En Redis-cache och S3-kompatibel fillagring med publika eller privata buckets deklareras på samma sätt, och GATE fyller i anslutningsuppgifterna åt varje tjänst.
Varje tjänst i GATE får en hälsokontroll på sin egen port, och en tjänst som inte klarar den två gånger i rad startas om automatiskt. Kontrollen kan peka på en sökväg som /healthz eller stängas av för en tjänst som inte talar HTTP, och företagets agent kan läsa tjänstens loggar när något går fel.
GATEs hosting startar inte en förhandsmiljö för varje pull request och lägger inte till fler kopior av en tjänst vid hög last: varje tjänst körs som en container från driftsättningsgrenen. Fillagringen har ingen webbkonsol, så objekt hanteras med valfri S3-klient. Externa nycklar, som en betalleverantörs, matas in av en person, eftersom bara företaget har dem.
GATE är endast via inbjudan medan GATE Intelligence tar in ett litet antal företag i taget. Efter inbjudan ber företaget sin agent att lägga appen på nätet: agenten skapar sajten från ett befintligt repo eller ett nytt privat, skriver gate.json och driftsätter. En ny webbplats för ett företag utgår från mockups som företaget först har godkänt.
Endast via inbjudan medan vi tar in ett litet antal företag.