Angular Generate App: ng new vs ng generate application Explained

To create an Angular app you run ng new for a fresh workspace with its first application, and you run ng generate application when you want an additional app inside an existing workspace.

The two commands sound interchangeable and are not. Choosing the right one up front decides how your repository is laid out for years.

Table of contents

• The two commands and when each applies
• Choices ng new asks you about
• What you get on disk
• Generating more than apps
• Running and building the app
• Deploying the build
• Environments, budgets and testing the generated app
• How this fits the rest of the stack
• FAQ

The two commands and when each applies

Angular’s command line tool creates projects with two related commands. They differ in scope.

ng new creates a new workspace. A workspace is the outer container: the configuration files, the package manifest, the build setup and, by default, one application inside it. Run it once at the start of a project.

ng generate application, which you can shorten to ng g application, adds another application to an existing workspace. It is for monorepo setups where one repository holds several apps that share libraries, such as a public site and an admin dashboard.

npm install -g @angular/cli
ng new storefront
cd storefront
ng generate application admin

After those commands the workspace contains two applications, each with its own entry point, configuration and build target, both under a projects directory. The official CLI reference documents every option, and it is the source to trust when flags change between versions.

If you only intend to build one app, you want ng new and nothing more. If you already know a second app will share most of its code with the first, consider a library for the shared code, which ng generate library creates, rather than copying components.

Choices ng new asks you about

When you run ng new the CLI asks a short series of questions, and each answer shapes the project.

• Stylesheet format. Plain CSS, Sass, Less. Pick what your team already uses, since changing later touches every component.
• Server-side rendering. Whether to include a server rendering setup and static pre-rendering. Choose it if search visibility or first-load speed matter for public pages. Skip it for authenticated dashboards where indexing is irrelevant.
• Routing. Usually yes, even for small apps.

Current versions create standalone components by default, which means components declare their own dependencies and you no longer need NgModules for new code. If you are following an older tutorial that begins with an app module, expect differences. The CLI reference notes the option to create an application based on the standalone API, without NgModules.

You can skip the prompts with flags, which is useful in scripts and continuous integration:

ng new storefront --style=scss --routing --ssr=false --skip-git

Using flags also documents the decision in your project setup notes. Decide these things deliberately, because SSR and style choices are easier to set at creation than to retrofit.

What you get on disk

The generated layout is more orderly than it first appears. At the workspace root you will find angular.json, which defines every project and its build, serve and test targets, a package.json with dependencies, and TypeScript configuration files.

Inside the application folder the important parts are:

• src/main.ts, the entry point that bootstraps the app.
• src/app/app.component.ts and its template and styles, the root component.
• src/app/app.config.ts, where providers such as the router are registered.
• src/index.html, the single HTML page that hosts the app.
• public or src/assets, static files copied to the output unchanged.

Learning where configuration lives saves a lot of searching. Build behaviour such as optimisation, budgets and file replacement for environments is in angular.json. Dependency versions are in package.json. Compiler strictness is in the TypeScript files.

Commit the whole workspace, including the lockfile, immediately. A clean first commit makes every later change a readable diff. If you need to understand the CLI more broadly, the existing posts on Angular first steps and the Angular project run command are good companions.

Generating more than apps

The same ng generate command, abbreviated ng g, produces the building blocks you use daily. Each saves boilerplate and keeps file naming consistent.

ng g component features/cart --standalone
ng g service core/cart
ng g pipe shared/currency-short
ng g directive shared/autofocus
ng g guard auth/admin
ng g library ui-kit

Use the --dry-run flag to preview exactly which files would be created without touching disk. It is a cheap way to confirm the path and naming before committing to a command, especially for deeply nested features.

A useful habit is to generate by feature folder rather than by type. A cart feature directory containing its component, service and tests is easier to find and to delete than separate folders for all components and all services across the whole app.

Run ng generate --help to list the schematics available in your installed version. Third party libraries add their own schematics, which is how some UI kits set themselves up with a single command rather than a page of instructions.

Running and building the app

Two commands cover most of your day. ng serve starts a development server with live reload, by default on port 4200. ng build compiles an optimised production bundle into the dist directory.

ng serve --port 4300
ng build --configuration production

The production build performs ahead-of-time compilation, tree-shaking and minification, and it enforces size budgets from angular.json. If a budget is exceeded the build warns or fails, which is a useful guardrail against accidentally shipping a huge bundle.

For a client-rendered app, the output is a folder of static files: an HTML page, JavaScript bundles and assets. Any static host can serve it, provided it falls back to index.html for unknown paths so that client-side routes like /products/42 work after a refresh. Missing that fallback is the most common cause of 404 errors on deep links after deployment.

If you added server-side rendering, the output also includes a server bundle that needs a Node runtime to run, which changes where you can host it.

Deploying the build

For a client-rendered Angular app the deployment path is simple: build in a clean environment and publish the output directory as a static site, with a single-page-app fallback rule.

On RunxBuild a static site builds from a GitHub repository, with custom domains, headers, redirects, rewrites and SPA fallback, and 120GB of bandwidth included before $0.10 per GB. For Angular you set the build command to npm run build and the output directory to the folder the build produces, which in current versions is a browser subfolder inside dist. The existing step-by-step on deploying an Angular app walks the screens, and the SPA fallback docs explain the routing rule.

If you use server-side rendering, deploy it as a Node web service instead, with the start command that runs the generated server file.

Environments, budgets and testing the generated app

Angular’s workspace configuration is where production behaviour is defined, so read it once. Under each project’s build options you will find budgets, which set warning and error thresholds for bundle size. The defaults are sensible. Tighten them as your app grows so a careless import of a large library fails the build instead of reaching users.

For environment-specific values such as API base URLs, avoid baking secrets into the bundle, because everything shipped to the browser is public. Public configuration can live in environment files swapped at build time, or in a small JSON file fetched at startup, which lets one build serve several environments. Never place private keys in client code.

Generate gives you test scaffolding too. Each component comes with a spec file, and ng test runs them. Add tests for services and guards first, since logic lives there, then for components that contain real behaviour. Wire ng build and ng test into continuous integration so a broken change fails before it merges.

When the app is ready, run ng build --configuration production locally and serve the output with any static server to confirm deep links work before you deploy.

How this fits the rest of the stack

A generated app is only the first line of the bill, because hosting, bandwidth and any API behind it follow. Estimate them before launch in the RunxBuild hosting calculator. When the build passes locally, the RunxBuild dashboard is where you connect the repository and publish it.

Useful related references:

• Free Angular Hosting: Build and Deploy an Angular App
• SSG in Angular: Prerendering With @angular/ssr, Step by Step
• The CLI in Angular: The Commands That Matter Day to Day
• Services on RunxBuild

FAQ

What is the difference between ng new and ng generate application?

ng new creates a whole new workspace with one starting application. ng generate application adds another application to an existing workspace, which suits repositories that hold several apps sharing code.

Does ng new use NgModules?

Current Angular versions generate standalone components by default, so new projects do not need an app module. Older tutorials that start with NgModule are written for earlier versions.

How do I create an Angular app without installing the CLI globally?

Use npx, for example npx @angular/cli new my-app. It downloads and runs the CLI for that command only.

Why do my Angular routes 404 after deployment?

Static hosts return 404 for paths that are not real files. Configure a single-page-app fallback that serves index.html for unknown routes so the Angular router can handle them.

Where does ng build put the output?

In the dist directory, in a folder named after your project. Recent versions place browser files in a browser subfolder, so set your host’s output directory to that path.