Frequently asked questions

Apposters turns a GitHub repository into a published website. You paste the repository link; an AI reads the project and writes a landing page for it, in your colours; you claim an address and the page is live at your-project.apposters.com.

The landing page is the start. In the same style you can add an About page, an FAQ page and a Sign In page, open a community for the people who register on your site and run the application itself on Apposters next to the site - from its Dockerfile, or without one for Node.js, Python, Go and static sites.

A link to a GitHub repository and an account. You can sign up with Google or with an email address and a password; if you paste the link on the homepage first, it travels with you through sign-up into the workspace.

Nothing to install and nothing to add to the repository: Apposters reads a public repository the way any visitor would, and a private one through your GitHub account once you authorize it (see the next answer). No card is needed either, see the pricing answers below.

A landing page is usually ready in a few minutes. The page streams into the builder as the AI writes it, so you watch it take shape rather than wait for a spinner. A whole website is generated one page after another, the landing page first and then About, FAQ and Sign In, so allow a few minutes per page.

Publishing is instant: claim an address and the site is live.

It has to be on GitHub; links to other code hosts are not recognised. Public or private is up to you. Apposters reads a public repository as an anonymous visitor. A private one looks to it like a repository that does not exist, so when you paste a link it cannot see, the workspace says so and offers Authorize with GitHub: you grant Apposters access to your repositories on GitHub, and from then on your private repositories are read with your own authorization, for the pages and for the Embed App alike. You can disconnect it in the workspace at any time, which also revokes the access on GitHub.

A private repository is generated as a SaaS only: a product site about what the app does, with the app itself running next to it, and nothing about the code. A landing page or a website is about the repository, and there is no point pointing visitors at one they cannot open.

The README, first of all: the README.md at the root of the default branch (that exact name; a readme.md, a README.rst or a README in a subfolder is not picked up) is the bulk of what the AI sees, up to about 60,000 characters of it, and where the copy, the feature list and the links come from. Alongside it Apposters passes the repository's public metadata: the description, the main language, the licence, the star, fork and watcher counts and the owner's avatar for the logo.

It does not clone the repository or read the source files, so the better the README explains the project, the better the page. A repository without a README still generates, from the metadata alone.

The Apposters backend sends a prompt to a large language model. The prompt carries your repository's README and metadata, the design you picked (or the one matched to your project) and the light or dark mode you chose and, for a website, the pages the menu has to link. The response is streamed straight into the builder as it arrives.

The extra pages are generated on top of the finished landing page, which is how they inherit its header, footer, colours and layout instead of getting a design of their own.

A SaaS site is written from the same README, but about the product the repository runs as - what the app does, for whom, how it helps - with no links to GitHub and nothing about the code; its buttons lead to the app itself, which you deploy next to the site with Embed App.

The choice is not final. The Project type card on a project's Overview switches it later - landing page, website or SaaS - and regenerates the landing page and the pages of the new type. The pages you had stay in each page's version history, so you can put them back.

Each page is a single HTML document with its styles and whatever small scripts it needs inside it. There is no build step and nothing proprietary around it: the file opens in any browser, any editor and any AI tool, so you can change it however you like and take it anywhere.

When you publish, Apposters adds the pieces a site needs around the content: a sitemap and robots.txt, Open Graph tags for link previews and an analytics tag (see the publishing answers).

Yes, before and after generation. Pick one of 30 designs - ten for each kind of site, from a quiet dark developer look to pixel art - each a complete design system with its own colours, fonts, corner radii and components. Leave it on Auto and Apposters picks the design that matches the repository's description and topics. Light or dark mode can be set on top of any of them.

Once a page exists you can regenerate it in a different design at any time: from the landing page's Design card, or from the project's Overview, which regenerates every page in the new look. Every generation is kept as a separate version, so you can compare them and go back.

Both. Every page has a visual editor for changing text and layout in place, and a code tab where the HTML is a text box you can edit or paste over entirely. Saving creates a new version, and the history keeps every generation and every edit, so any earlier one can be restored.

Publishing is a separate step: an edit goes live only when you publish it, so you can work on the next version while the current one stays up.

At https://your-name.apposters.com, over HTTPS, with the extra pages under it: /about, /faq, /auth. You choose the name when you publish: 3 to 60 characters, lowercase letters, digits and hyphens, and it has to be free; a few names Apposters uses itself are reserved.

You can change it later, on the project's Overview, and the page keeps its members and its visit history. Choose it with care all the same: the old address is released - links to it and its place in search results stop working, and the name is free for someone else to take.

Yes. Open the project's Overview and enter your domain in the Custom domain card: one domain per site, www.example.com or example.com. A site that has no apposters.com address yet gets one at that moment, picked from its name (you can change it in the Address card any time before publishing) - the domain is pointed at it. The card shows the DNS record to add at your registrar: a CNAME to your apposters.com subdomain, or an A record to the Apposters IP together with a small TXT record that proves the domain is yours. Press Verify; when the records are found, Apposters issues the HTTPS certificate on its own, usually within a few minutes, and the site answers on your domain, with the extra pages and the app under it (www.example.com/about, www.example.com/app). The apposters.com subdomain keeps working alongside.

Custom domains are a paid feature; the price and the payment terms are on the card and on Stripe's payment page before you pay (see Pricing). Removing a domain is always free, and the subdomain stays up.

At publish time every page gets a sitemap.xml and robots.txt on its subdomain, Open Graph and Twitter Card tags with a screenshot of the page as the preview image (taken automatically after publishing), and a Google Analytics tag: your own GA4 property if you enter its ID on the project's Overview, otherwise the shared Apposters property, so the page is measured either way.

Apposters also counts every opening of the landing page and shows the number on the Overview. The projects featured on the apposters.com homepage are chosen by the Apposters team and ranked by those visits; write to support if you would like yours considered.

Making and publishing a site is free: the landing page, the About, FAQ and Sign In pages, the versions and the editor, the address on apposters.com, registrations and the community.

Two features are paid, each on its own: Embed App, which runs your application on Apposters, and a custom domain for your site; an app on Embed App can also be given more memory and disk. The price and the payment terms of each are on the Pricing page, on its screen (the Embed App screen, the Custom domain card on the Overview) and on the payment page before you pay; payment goes through Stripe.

No. Signing up, generating and publishing a site need no card and no billing details.

A card comes in only if you decide to run your application with Embed App or to connect your own domain, and then it is handled on Stripe's payment page: Apposters never sees or stores card details.

For Embed App, only the actions that put an application on a server: configuring a deployment, building and deploying it, starting and restarting the container. Everything else on the Embed App screen stays open regardless: you can always see, stop, read the logs of and remove an app that is already running, and an app deployed before payment was introduced keeps running.

For a custom domain, connecting one and checking its DNS. A domain connected before payment was introduced keeps answering, and removing it always works.

Nothing about the website is affected: the landing page and the extra pages stay published and free on their apposters.com address.

Embed App runs the software in the repository on Apposters, at /app on the landing page's own address (for example my-project.apposters.com/app, or www.your-domain.com/app once you connect a domain), with HTTPS, logs, metrics, environment variables and a terminal in the browser. The server side of your app needs no base path for that: the /app prefix is taken off before the request reaches it, so an app that serves at / answers as it is. An app that routes in the browser (React Router, TanStack Router, Next.js, Vue Router and the like) is different: it reads the address bar, so it needs its base path set to /app in the repository, or it shows a blank page. Apps also run within limits - memory (512 MB), disk (3 GB for the image and its data together), build time - and when one does not fit, the Embed App screen says which limit it hit and by how much. More memory and disk can be bought for an app on that screen, and more disk also lets a bigger image in.

If the repository has a Dockerfile, Apposters builds the image from it. If it does not, Apposters recognizes the project by its files - Vite, Next.js, React, Vue, Angular, Astro, Express, Django, FastAPI, Flask, Streamlit, Go or a plain index.html - and writes the Dockerfile itself (vercel.json build settings are honored). Either way it starts a container that listens on the port you set (3000 by default, passed in as PORT, bound to 0.0.0.0) and answers a health-check path before traffic is switched to it; if a new build does not come up, the previous one keeps serving. Something else entirely? Start a bare Linux box instead (Ubuntu, Debian, Alpine, Node or Python images) and set it up from the terminal. Limits: one app per account, 512 MB of memory, one CPU and 20 builds a day.

Files written to the data path you set on the deployment screen live on a volume that survives redeploys, restarts and environment changes; everything else in the container is rebuilt from the image on each deploy. On a bare box the installed software is snapshotted too, so it survives stops and restarts; only Recreate starts from a clean image, and Reset data cannot be undone.

There are no automatic backups yet, and no uptime guarantee: after a server maintenance reboot an app stays stopped until you start it again from the screen. Keep anything you cannot lose in a place you control.

Publishing a site turns on sign-in for it: visitors register at your-name.apposters.com/auth with an email address and a password, and the Sign In page you can generate is that front door in your site's design. The people who register are listed on your project's Users screen.

Switch on Community Platform and they also get a forum for your project: a private space on community.apposters.com, reached from your-name.apposters.com/community, where only your registered users can read and post, with you as moderator and one login for the site and the forum.

Yes, from the Danger zone at the bottom of the project's Overview. Deleting removes the project and its whole version history from your workspace; tick the box to also take the live site offline and delete its files, otherwise the published page stays up at its address. A hosted app is removed together with the project: the container, the image and the data volume.

The community forum is not deleted automatically; write to support and we remove it by hand. Deleting your whole account also goes through support for now.

Write to support@apposters.com: questions, bugs, a project you would like featured, or a forum or account you want removed. For a bug, the address of the site or the app, what you did and what you expected is enough to start with.

You can also find Apposters on GitHub at github.com/apposters.